6 ms·

Its fun and games until you find out one of the things you bundled into your static binary has a remote code execution CVE that is being actively exploited in t

Its fun and games until you find out one of the things you bundled into your static binary has a remote code execution CVE that is being actively exploited in the wild. Good luck tracking down all the artifacts and making sure they are rebuild with the patched version - till the time next CVE hits and you can do it all again for every static binary bundling the affected component.

marcinzm 6y ago
I mean, containers are basically just that and people seem to like them just fine.
- ethbro 6y ago
  People seem to like them just fine != People are patching CVEs
  - marcinzm 6y ago
    That's a question of process and tooling. Plenty of software, OSS and proprietary, which scans containers for vulnerabilities and sends out alerts. There's also dependabot that automatically creates PRs when dependencies get new versions. Sure people may not use the tools they have but then again people also don't upgrade their OS packages or maven packages. So for those people packaging everything doesn't hurt any more since they've got rampant CVEs already.
- ClumsyPilot 6y ago
  Exactly, container is a way to package all these disorganised, chaotic snowflake languages into something you can actually run in a standard way. It full fills the function of an executable, but at a higher level of abstraction. We've come full circle again.
- vmchale 6y ago
  Containers solve a different problem.
closeparen 6y ago
Rolling out a new binary is a happy path process that gets used all the time; what's the problem here?
- Spivak 6y ago
  Yeah, I don't really understand the hate containers get for this. If the people who run your software aren't updating it you're screwed anyway. I promise you'll be way more disappointed if you assume that the system libs in the wild will be patched and up to date. Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense.
  - deleted 6y ago
    [deleted]
  - naniwaduni 6y ago
    > If the people who run your software aren't updating it you're screwed anyway. They're screwed. Hopefully you aren't. Hopefully.
  - cbmuser 6y ago
    > Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense. The problem is that distributions get their software from upstream developers. And if upstream decides to go static or use embedded code copies, the maintainers have much more work trying to untangle everything. In my experience, packaging Go software for Linux distributions is very frustrating and tedious because of that. Packaging Python or C/C++ software is much easier.
    - dgoldstein0 6y ago
      is it really that bad to distribute statically-linked go binaries in a distro? Or rather, perhaps the better question - what's the dynamic linking benefit that a distro can't live without? Wondering since the application developers I know seem to prefer static linking.
mdoms 6y ago
There's no reason whatever binary packaging format you use can't store metadata on all of its internal dependencies. "Tracking down" vulnerable dependencies is almost trivial in this case.
- sergeykish 6y ago
  And this metadata could point on the region so it could be swapped easily. Oh wait..
pjc50 6y ago
But this doesn't necessarily work in the "loose binding" world either - because people pin their dependencies to a specific version to avoid breakage. There's a fundamental unresolvable tension in automatic update systems between "not updating breaks things" and "updating breaks things"; you cannot solve for both at once and either one will get users mad at you, although not upgrading at least gives a pushback argument. See how all this has played out with Windows and Mac updates, for example.
- m4rtink 6y ago
  Pinning dependencies to specific version is also bad - that's lazy engineering & instant technical debt. You really should check what APIs your dependencies provide and how stable that API is, then set minimal dependency version. If you set the dependency to a specific version, you are creating a headache for anyone trying to use your software later on (by potentially forcing them to use oudated and insecure software) and for distro maintainers trying to keep distro software up to date and secure. What if the dependency is so unstable that you have to pin the version or even use custom patched version? Well, thenaybe its not somethong you should be depending on & rather use something with less features but more stable. Othervise you are really being unresponsible - using quick convenience at the cost of long term usability of your software.
  - dgoldstein0 6y ago
    I'm not sure exactly what form of dependency pinning you are hating on - but if you are suggesting we should ditch dep-pinning altogether, I have to totally disagree. It's never a good experience to wake up one day and see that your code that worked yesterday, no longer does; or worse, that it works for you but other people start saying otherwise. Failing to pin deps (e.g. with a lockfile) makes it rather easy for these bugs to slip in - it's just one accidental backwards-incompatible change in a transitive dependency of yours away, and good luck figuring out how to reproduce the problem reliably.
    - m4rtink 6y ago
      I should have mentioned that I'm seeing this from the point of view of a distro maintainer involved in Fedora. The thing is that in general you don't want to have many version of libraries available in the distro in parallel as each has to be separately maintained, security patches applied, build issues fixed, etc., eating valuable maintainer time. Also in some cases libraries of different version can't coexist on a system cleanly. Then imagine every piece of software just pins versions of their dependencies to a specific random version that happened to work at the time. To satisfy those arbitrary dependencies the distro would have to maintain all these versions at the same time, which is simply impossible resource vise, not to mention incredibly wasteful (both in maintainer time & system resources). As for stuff breaking if you don't pin dependency version - well, distros have mechanisms to handle that. For example for Fedora, there is a stable release very 6 months & stable releases are not expected to get major changes in libraries, just bug fixes and smaller enhancements. And at the same time there is a rolling version of Fedora called Rawhide, where all the latest package versions land and where integration issues are addressed. So any breakage would happen on Rawhide and be addressed by maintainers (of the library/software affected or both) long before a new stable release is cut from Rawhide and users will actually use it. For an example I'm maintaining the PyOtherSide Qt 5/Python bindings on Fedora. A while ago the build failed due to Python being updated to 3.9. I reported the issue upstream, which quickly fixed it and I've built an updated version in Rawhide. All this long before a stable Fedora version will get Python 3.9, but I can be sure that when this happens, all will work fine.
earthboundkid 6y ago
What’s the scenario where dynamic libraries are regularly upgraded but static binaries are not? Just seems totally non-sequitur as a reason to prefer dynamic libraries.
- m4rtink 6y ago
  You mean like any normal Linux distro ? Dynamic libraries installed from packages in the repositories will get updated automatically while random static binaries downloaded from the internet or built from source will just sit there perfectly stable and unchanging and progressively more vulnerable, unless the user takes an action.
  - sixbrx 6y ago
    That's not static vs. dynamic though, that's "in package manager system" vs not. If package managers managed static binaries, they'd all be updated too since the package manager knows all the dependencies.
    - sergeykish 6y ago
      But what is the point of static compilation if maintainers update dependencies? Either dependencies defined by author or maintainers. Dynamic libraries just help to automate roll out. And users would find outdated versions (maybe unmaintained). Current system update dependencies automatically or allow collaboration on life support (patched application, dependencies, config). It would be good to have alternative like container or virtual machine with snapshot from the days long past. But it should be clear this is not safe.
- sergeykish 6y ago
  Developer who missed CVE. Not anyone has fulltime job on his project. It could result on even more shaming of open source developers (if they freeze dependencies).
  - earthboundkid 6y ago
zaphar 6y ago
This issue has different risk profiles based on the target user base. If the install is on a consumer machine for regular usage then the right answer is shared libraries for the machine. It adds a lot of complexity for the packagers for that OS but you get a lot of safety for that consumer. If the install is an inhouse app deploying to servers a company controls/rents whatever then the right answer is probably a static application. Consumers are more likely to want to chase the latest version of everything. Company developed software is far less likely to want that. The problem then becomes less about packaging and more about deploying fixes quickly. A static binary that is rebuilt, tested, and deployed is going to be a smoother path to fixing that error than figuring out how to deploy your new shared library and avoiding any issues in our production environment caused by clashes to that library. This is made more problematic by the likelihood that you will need multiple versions of that shared library with the fix to meet the needs of applications that can not yet be upgraded. Static binaries make things easier in this scenario and thus quicker to resolve.
vmchale 6y ago
Some ecosystems allow you to do that, no?

marcinzm 6y ago

I mean, containers are basically just that and people seem to like them just fine.

ethbro 6y ago
People seem to like them just fine != People are patching CVEs
- marcinzm 6y ago
  That's a question of process and tooling. Plenty of software, OSS and proprietary, which scans containers for vulnerabilities and sends out alerts. There's also dependabot that automatically creates PRs when dependencies get new versions. Sure people may not use the tools they have but then again people also don't upgrade their OS packages or maven packages. So for those people packaging everything doesn't hurt any more since they've got rampant CVEs already.
ClumsyPilot 6y ago
Exactly, container is a way to package all these disorganised, chaotic snowflake languages into something you can actually run in a standard way. It full fills the function of an executable, but at a higher level of abstraction. We've come full circle again.
vmchale 6y ago
Containers solve a different problem.

closeparen 6y ago

Rolling out a new binary is a happy path process that gets used all the time; what's the problem here?

Spivak 6y ago
Yeah, I don't really understand the hate containers get for this. If the people who run your software aren't updating it you're screwed anyway. I promise you'll be way more disappointed if you assume that the system libs in the wild will be patched and up to date. Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense.
- deleted 6y ago
  [deleted]
- naniwaduni 6y ago
  > If the people who run your software aren't updating it you're screwed anyway. They're screwed. Hopefully you aren't. Hopefully.
- cbmuser 6y ago
  > Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense. The problem is that distributions get their software from upstream developers. And if upstream decides to go static or use embedded code copies, the maintainers have much more work trying to untangle everything. In my experience, packaging Go software for Linux distributions is very frustrating and tedious because of that. Packaging Python or C/C++ software is much easier.
  - dgoldstein0 6y ago
    is it really that bad to distribute statically-linked go binaries in a distro? Or rather, perhaps the better question - what's the dynamic linking benefit that a distro can't live without? Wondering since the application developers I know seem to prefer static linking.

mdoms 6y ago

There's no reason whatever binary packaging format you use can't store metadata on all of its internal dependencies. "Tracking down" vulnerable dependencies is almost trivial in this case.

sergeykish 6y ago
And this metadata could point on the region so it could be swapped easily. Oh wait..

pjc50 6y ago

But this doesn't necessarily work in the "loose binding" world either - because people pin their dependencies to a specific version to avoid breakage. There's a fundamental unresolvable tension in automatic update systems between "not updating breaks things" and "updating breaks things"; you cannot solve for both at once and either one will get users mad at you, although not upgrading at least gives a pushback argument. See how all this has played out with Windows and Mac updates, for example.

m4rtink 6y ago
Pinning dependencies to specific version is also bad - that's lazy engineering & instant technical debt. You really should check what APIs your dependencies provide and how stable that API is, then set minimal dependency version. If you set the dependency to a specific version, you are creating a headache for anyone trying to use your software later on (by potentially forcing them to use oudated and insecure software) and for distro maintainers trying to keep distro software up to date and secure. What if the dependency is so unstable that you have to pin the version or even use custom patched version? Well, thenaybe its not somethong you should be depending on & rather use something with less features but more stable. Othervise you are really being unresponsible - using quick convenience at the cost of long term usability of your software.
- dgoldstein0 6y ago
  I'm not sure exactly what form of dependency pinning you are hating on - but if you are suggesting we should ditch dep-pinning altogether, I have to totally disagree. It's never a good experience to wake up one day and see that your code that worked yesterday, no longer does; or worse, that it works for you but other people start saying otherwise. Failing to pin deps (e.g. with a lockfile) makes it rather easy for these bugs to slip in - it's just one accidental backwards-incompatible change in a transitive dependency of yours away, and good luck figuring out how to reproduce the problem reliably.
  - m4rtink 6y ago
    I should have mentioned that I'm seeing this from the point of view of a distro maintainer involved in Fedora. The thing is that in general you don't want to have many version of libraries available in the distro in parallel as each has to be separately maintained, security patches applied, build issues fixed, etc., eating valuable maintainer time. Also in some cases libraries of different version can't coexist on a system cleanly. Then imagine every piece of software just pins versions of their dependencies to a specific random version that happened to work at the time. To satisfy those arbitrary dependencies the distro would have to maintain all these versions at the same time, which is simply impossible resource vise, not to mention incredibly wasteful (both in maintainer time & system resources). As for stuff breaking if you don't pin dependency version - well, distros have mechanisms to handle that. For example for Fedora, there is a stable release very 6 months & stable releases are not expected to get major changes in libraries, just bug fixes and smaller enhancements. And at the same time there is a rolling version of Fedora called Rawhide, where all the latest package versions land and where integration issues are addressed. So any breakage would happen on Rawhide and be addressed by maintainers (of the library/software affected or both) long before a new stable release is cut from Rawhide and users will actually use it. For an example I'm maintaining the PyOtherSide Qt 5/Python bindings on Fedora. A while ago the build failed due to Python being updated to 3.9. I reported the issue upstream, which quickly fixed it and I've built an updated version in Rawhide. All this long before a stable Fedora version will get Python 3.9, but I can be sure that when this happens, all will work fine.

earthboundkid 6y ago

What’s the scenario where dynamic libraries are regularly upgraded but static binaries are not? Just seems totally non-sequitur as a reason to prefer dynamic libraries.

m4rtink 6y ago
You mean like any normal Linux distro ? Dynamic libraries installed from packages in the repositories will get updated automatically while random static binaries downloaded from the internet or built from source will just sit there perfectly stable and unchanging and progressively more vulnerable, unless the user takes an action.
- sixbrx 6y ago
  That's not static vs. dynamic though, that's "in package manager system" vs not. If package managers managed static binaries, they'd all be updated too since the package manager knows all the dependencies.
  - sergeykish 6y ago
    But what is the point of static compilation if maintainers update dependencies? Either dependencies defined by author or maintainers. Dynamic libraries just help to automate roll out. And users would find outdated versions (maybe unmaintained). Current system update dependencies automatically or allow collaboration on life support (patched application, dependencies, config). It would be good to have alternative like container or virtual machine with snapshot from the days long past. But it should be clear this is not safe.
sergeykish 6y ago
Developer who missed CVE. Not anyone has fulltime job on his project. It could result on even more shaming of open source developers (if they freeze dependencies).
- earthboundkid 6y ago

zaphar 6y ago

This issue has different risk profiles based on the target user base. If the install is on a consumer machine for regular usage then the right answer is shared libraries for the machine. It adds a lot of complexity for the packagers for that OS but you get a lot of safety for that consumer. If the install is an inhouse app deploying to servers a company controls/rents whatever then the right answer is probably a static application. Consumers are more likely to want to chase the latest version of everything. Company developed software is far less likely to want that. The problem then becomes less about packaging and more about deploying fixes quickly. A static binary that is rebuilt, tested, and deployed is going to be a smoother path to fixing that error than figuring out how to deploy your new shared library and avoiding any issues in our production environment caused by clashes to that library. This is made more problematic by the likelihood that you will need multiple versions of that shared library with the fix to meet the needs of applications that can not yet be upgraded. Static binaries make things easier in this scenario and thus quicker to resolve.

vmchale 6y ago

Some ecosystems allow you to do that, no?