5 ms·

Examples of CVEs in libpng and libvorbis are not exactly hard to find: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-b

Examples of CVEs in libpng and libvorbis are not exactly hard to find: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7317 If your nontrivial game has an online component with voice chat or custom avatars or something like that, then you now have an attack vector. If your game is closed source, I hope you are following updates from these libraries and either updating your vendored copy or backporting patches and then immediately pushing out a new release whenever an upstream update is published. And you will likely want to be committed to doing this for however many years you plan to keep your game online. And if you're going through all the trouble of doing that, I don't see what benefit you're getting from static linking these libraries anymore. (Unless the argument is that you're going to patch it faster than the distros)

danShumway 6y ago
And if your nontrivial game doesn't have an online component, then you don't have an attack vector. For a lot of games, you're never going to deal with user-submitted audio files. If you do have an online component or mod-loader that's affected by a vulnerability, you'll still find that the amount of work required to recompile a game and ship an update when a security release is issued for a dependency is less than the amount of work required to deal with accidental breaking changes in minor version updates, or with systems that don't install the latest package versions, or with systems that have renamed their libraries, or with systems that have stuck custom incompatible patches on top of their libraries. If you're monitoring CVE releases for your statically linked dependencies, then when something breaks you push one patch and that's it, you're done. The alternative is that the problem never, ever goes away because people don't keep their systems up to date, and they have weird setups, and there's no patch you can ship to address that problem. You really don't want to be in a position where you're supporting multiple versions of the same library. When a security patch gets issued, you're going to do the same amount of testing regardless, so you might as well ship one version of the library at the end of that testing process that you know will work. Aside from the support issue, there's also the fact that for security reasons you'd really like to fix most security bugs in your app yourself anyway, because, again, people don't keep their systems up to date, so it doesn't matter how quickly distros patch their libraries. If you don't ship an update that fixes the issue for everyone, then it won't be fixed for everyone. You can't trust users to update their own system libraries or not to forcibly maintain older versions, and for any app that needs to maintain a reputation of security (ie, most encrypted chat apps and password managers), you don't want your users to get hacked just because they were using a shared library ended up being vulnerable. And even that's ignoring the fact that there are tradeoffs even for security fixes. If we're talking about a 10 year old game that's been abandoned, we'd like to have the ability to easily run it, even if we acknowledge that it might have some security holes. But ultimately, this is really not worth fighting about. Prove Ethan wrong, try shipping dozens of commercial games with the strategy you propose and see whether or not your support requests go up or down. There's a reason game devs overall trend towards statically linking libraries. We're not doing it just to be difficult.
- xfer 6y ago
  Well, the trick is to ship your own libpng/libvorbis linked dynamically. So you only update a tiny library than half a gigabyte executable when you need a security fix. You also don't depend on the distro to provide the library. In fact a lot of indie games that support linux do it this way, setting LD_LIBRARY_PATH with a shell script and it works well.
- cycloptic 6y ago
  It seems like this is coming down to a wager that you can get security updates out faster than a distro. Short-term this is probably true, long-term I doubt it. The incentives are not there for you. If a 10 year old game has been abandoned, I don't mind testing or recompiling it for some security updates. I've done this for lots of open source games. I personally would never work on a closed source game, so most of what you/Ethan are talking about doesn't concern me. The situation changes when you stop trying to sidestep distro maintainers, and start committing to working with them. I get that it's inconvenient to do that and you're not just being difficult, but surely you know the trade-offs.
gridlockd 6y ago
This is how it is done on Windows, which is a far more successful game platform than Linux. Obviously you need to dynamically link to OS interfaces, but you either statically link or ship with your dependencies. On Linux, relying on system provided dependencies, especially C++ ones, is guaranteed to break over time and over different distributions. So you would have to maintain your Linux version either way, shipping with your dependencies is just less insane.
- cycloptic 6y ago
  It's not guaranteed to break if you actually work with the distro maintainers. They don't want your packages breaking either.
  - gridlockd 6y ago
    Maintainers aren't going to keep outdated packages around forever, even if you "work with them". In effect, there is some ongoing maintenance there either way. If I just maintain my own dependencies, then I don't have to work with maintainers from a dozen distributions.
    - cycloptic 6y ago
      >Maintainers aren't going to keep outdated packages around forever, even if you "work with them". In general, yes they will. You don't have to do much besides communicate to them that it's safe to bump a dependency and won't cause breakage. And you don't have to track down a dozen maintainers either, simply putting it in your release notes where they can find it is enough. The main reason why packages are dropped is because of lack of maintenance, possibly caused by absent or unresponsive upstream. That's what outdated means. Do you think packagers are going through all the trouble of dropping unmaintained versions of Python 2 on a whim?

danShumway 6y ago

And if your nontrivial game doesn't have an online component, then you don't have an attack vector. For a lot of games, you're never going to deal with user-submitted audio files. If you do have an online component or mod-loader that's affected by a vulnerability, you'll still find that the amount of work required to recompile a game and ship an update when a security release is issued for a dependency is less than the amount of work required to deal with accidental breaking changes in minor version updates, or with systems that don't install the latest package versions, or with systems that have renamed their libraries, or with systems that have stuck custom incompatible patches on top of their libraries. If you're monitoring CVE releases for your statically linked dependencies, then when something breaks you push one patch and that's it, you're done. The alternative is that the problem never, ever goes away because people don't keep their systems up to date, and they have weird setups, and there's no patch you can ship to address that problem. You really don't want to be in a position where you're supporting multiple versions of the same library. When a security patch gets issued, you're going to do the same amount of testing regardless, so you might as well ship one version of the library at the end of that testing process that you know will work. Aside from the support issue, there's also the fact that for security reasons you'd really like to fix most security bugs in your app yourself anyway, because, again, people don't keep their systems up to date, so it doesn't matter how quickly distros patch their libraries. If you don't ship an update that fixes the issue for everyone, then it won't be fixed for everyone. You can't trust users to update their own system libraries or not to forcibly maintain older versions, and for any app that needs to maintain a reputation of security (ie, most encrypted chat apps and password managers), you don't want your users to get hacked just because they were using a shared library ended up being vulnerable. And even that's ignoring the fact that there are tradeoffs even for security fixes. If we're talking about a 10 year old game that's been abandoned, we'd like to have the ability to easily run it, even if we acknowledge that it might have some security holes. But ultimately, this is really not worth fighting about. Prove Ethan wrong, try shipping dozens of commercial games with the strategy you propose and see whether or not your support requests go up or down. There's a reason game devs overall trend towards statically linking libraries. We're not doing it just to be difficult.

xfer 6y ago
Well, the trick is to ship your own libpng/libvorbis linked dynamically. So you only update a tiny library than half a gigabyte executable when you need a security fix. You also don't depend on the distro to provide the library. In fact a lot of indie games that support linux do it this way, setting LD_LIBRARY_PATH with a shell script and it works well.
cycloptic 6y ago
It seems like this is coming down to a wager that you can get security updates out faster than a distro. Short-term this is probably true, long-term I doubt it. The incentives are not there for you. If a 10 year old game has been abandoned, I don't mind testing or recompiling it for some security updates. I've done this for lots of open source games. I personally would never work on a closed source game, so most of what you/Ethan are talking about doesn't concern me. The situation changes when you stop trying to sidestep distro maintainers, and start committing to working with them. I get that it's inconvenient to do that and you're not just being difficult, but surely you know the trade-offs.

gridlockd 6y ago

This is how it is done on Windows, which is a far more successful game platform than Linux. Obviously you need to dynamically link to OS interfaces, but you either statically link or ship with your dependencies. On Linux, relying on system provided dependencies, especially C++ ones, is guaranteed to break over time and over different distributions. So you would have to maintain your Linux version either way, shipping with your dependencies is just less insane.

cycloptic 6y ago
It's not guaranteed to break if you actually work with the distro maintainers. They don't want your packages breaking either.
- gridlockd 6y ago
  Maintainers aren't going to keep outdated packages around forever, even if you "work with them". In effect, there is some ongoing maintenance there either way. If I just maintain my own dependencies, then I don't have to work with maintainers from a dozen distributions.
  - cycloptic 6y ago
    >Maintainers aren't going to keep outdated packages around forever, even if you "work with them". In general, yes they will. You don't have to do much besides communicate to them that it's safe to bump a dependency and won't cause breakage. And you don't have to track down a dozen maintainers either, simply putting it in your release notes where they can find it is enough. The main reason why packages are dropped is because of lack of maintenance, possibly caused by absent or unresponsive upstream. That's what outdated means. Do you think packagers are going through all the trouble of dropping unmaintained versions of Python 2 on a whim?