3 ms·

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with met

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates. And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

xyzzy123 6y ago
IMHO the ideal situation is that both distribution mechanisms are available; single file static binary and also packages for different OS's. Which one you want to use in a given situation is contextual. Murphy's law seems to dictate that the version of the build tool lovingly cared for by the OS's package manager is never the version you actually need. Build tools in particular have a slightly different lifecycle to many things running on a host, which are "owned", cared for and configured by a system administrator. Usually the project you're building "owns" the version of the build tool it needs and there's no guarantee that it will build with a different version. As a consequence, genuine build tool security issues must first be handled by the team making the tool and then by the projects depending on it when they verify compatibility.
jrockway 6y ago
> I want my binaries to use shared objects so that an entire OS can receive quick security updates. Have shared libraries historically improved security much? Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. Personally, I don't think there's enough software on the average filesystem image to justify sharing libraries. Most stuff "in production" these days is in a container, which shares nothing with the other containers running on the same VM, which share nothing with the other VMs running on the same bare metal server. In the case of containers, a full rebuild from source is just as easy as updating a shared library -- maybe even easier. So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries. (The high cost is having to maintain binary compatibility with applications you've never even seen before.) The whole reason things like "Linux distributions" exist is for some central authority to coordinate and handle all the breakages this model causes. It's nice that they do it for us, but it's kind of makework to save a few bytes of network transfer now and again. Doesn't seem worth it to me. > I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy. You've just invented containers. Many other people agree with you, which is why they became so popular.
- surajrmal 6y ago
  I too used to take this view until I worked on a system which was on a limited storage budget of roughly 500MiB. Shared libraries go a long ways on a system like that towards making the entire thing fit. The other option was linking multiple binaries together busybox style, which also works wonders, although it forces release coupling so there are tradeoffs. Not every linux system is for desktop or server either.
- eeZah7Ux 6y ago
  > Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. I'm going to guess you never checked how many vulnerabilities have been fixed in Linux distributions before a release, or backported to existing releases: hundreds of thousands. Cherry-picking a single incident (involving a library with a history of vulnerabilities) is hardly meaningful. > Most stuff "in production" these days is in a container It's provably not, outside of the SV bubble. The large majority of software in the world is still deployed traditionally. > So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries A good number of large companies think otherwise. Also, people working in security. >> I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy. > You've just invented containers. No, these are OS packages and predate containers by many decades. This is getting silly.

xyzzy123 6y ago

IMHO the ideal situation is that both distribution mechanisms are available; single file static binary and also packages for different OS's. Which one you want to use in a given situation is contextual. Murphy's law seems to dictate that the version of the build tool lovingly cared for by the OS's package manager is never the version you actually need. Build tools in particular have a slightly different lifecycle to many things running on a host, which are "owned", cared for and configured by a system administrator. Usually the project you're building "owns" the version of the build tool it needs and there's no guarantee that it will build with a different version. As a consequence, genuine build tool security issues must first be handled by the team making the tool and then by the projects depending on it when they verify compatibility.

jrockway 6y ago

> I want my binaries to use shared objects so that an entire OS can receive quick security updates. Have shared libraries historically improved security much? Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. Personally, I don't think there's enough software on the average filesystem image to justify sharing libraries. Most stuff "in production" these days is in a container, which shares nothing with the other containers running on the same VM, which share nothing with the other VMs running on the same bare metal server. In the case of containers, a full rebuild from source is just as easy as updating a shared library -- maybe even easier. So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries. (The high cost is having to maintain binary compatibility with applications you've never even seen before.) The whole reason things like "Linux distributions" exist is for some central authority to coordinate and handle all the breakages this model causes. It's nice that they do it for us, but it's kind of makework to save a few bytes of network transfer now and again. Doesn't seem worth it to me. > I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy. You've just invented containers. Many other people agree with you, which is why they became so popular.

surajrmal 6y ago
I too used to take this view until I worked on a system which was on a limited storage budget of roughly 500MiB. Shared libraries go a long ways on a system like that towards making the entire thing fit. The other option was linking multiple binaries together busybox style, which also works wonders, although it forces release coupling so there are tradeoffs. Not every linux system is for desktop or server either.
eeZah7Ux 6y ago
> Debian helpfully "updated" OpenSSL, and thanks to the magic of shared libraries, every program on a Debian system generated weak keys. I'm going to guess you never checked how many vulnerabilities have been fixed in Linux distributions before a release, or backported to existing releases: hundreds of thousands. Cherry-picking a single incident (involving a library with a history of vulnerabilities) is hardly meaningful. > Most stuff "in production" these days is in a container It's provably not, outside of the SV bubble. The large majority of software in the world is still deployed traditionally. > So the "quick security updates" doesn't seem to justify the high maintainability cost of shared libraries A good number of large companies think otherwise. Also, people working in security. >> I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy. > You've just invented containers. No, these are OS packages and predate containers by many decades. This is getting silly.