5 ms·

That's not a difference of security, only of download size (*). A statically-linking distro would queue up those thousand packages to be rebuilt and you would r

That's not a difference of security, only of download size (*). A statically-linking distro would queue up those thousand packages to be rebuilt and you would receive them via OS update, just as you would with a dynamically-linking distro. The difference is just in whether you have to download 1000 updated packages or 1. And on a distribution like OpenSUSE TW, the automation is set up such that those thousand packages do get rebuilt anyway, even though they're dynamically linked. (*): ... and build time on the distro package builders, of course.

singron 2y ago
The build time is pretty significant actually. E.g. NixOS takes this to the extreme and always rebuilds packages if their dependencies change. It can take days to rebuild affected packages, and you typically can't easily update in the meantime. This is worse if the rebuild breaks something since someone will have to fix or revert that before it can succeed. For non-security updates, they can do the rebuild in a branch (staging) so it's non-blocking, but you will feel the pain on a security update. In practice, users will apply a config mitigation if available or "graft" executables against an updated lib using system.replaceDependencies, which basically search and replaced the built artifacts to use a different file path.
- Arnavion 2y ago
  True. I'm involved in Alpine, postmarketOS and OpenSUSE packaging and I've seen builders of the first two become noticeably slow on mass rebuilds. OpenSUSE tends to be fine, but it has a lot of builders so that's probably why.
- JackSlateur 2y ago
  It shall be noted that there is no need to recompile everything, when a library's patched: you only need to relink the executables and rebuild the packages Still, this requires a somewhat bigger infrastructure
robert_foss 2y ago
Security + build time isn't the issue, but security + dev/testing time is. Maintaining a secure package of zlib takes linearly more time with more versions of it used. All distros are manpower limited.
- Arnavion 2y ago
  There's only one version of zlib, the distro-packaged version, in the scenario of this discussion.
  - CRConrad 2y ago
    As I read it, that's 100% wrong: Isn't the discussion precisely about using the distro-packaged version vs. having other versions statically linked?
throw0101c 2y ago
> That's not a difference of security, only of download size (*). It is a difference of security, because now when there's an issue with (e.g.) OpenSSL, instead of just the OpenSSL distro package team having to worry about it, the MySQL distro package team has to, the Postgres distro package team, Nginx, Apache, cURL, OpenSSH, etc. All of those teams have to coordinate to release at the same time.
- Arnavion 2y ago
  We're talking about distro packages, not upstream software releases.
  - throw0101c 2y ago
    > We're talking about distro packages, not upstream software releases. Yes, by "the MySQL package team" I meant the MySQL distro package team. Edited to clarify. But even if applied to the upstream team that releases from (e.g.) repo.mysql.org or repo.postgres.org it would apply: they're now worrying about all their dependencies as well their own code, instead of just specifying in the .deb or .rpm file "I need libssl3" and letting the OS take care of it. It would become a huge duplication of effort to keep up on security updates. At $JOB we have a general policy to always use the distro-supplied version of a package whenever possible, as if we compile it on our own and put it into /usr/local or /opt, we now have to babysit that code for security and such ourselves instead of 'outsourcing' it to the distro. Ain't nobody got time for that.
ndiddy 2y ago
It is a difference of security. As one example, Debian used to be more lenient on allowing packages to vendor and statically link libraries. Around 20 years ago, an important zlib vulnerability was found that could be exploited through malicious compressed data. Rather than just pushing out a fixed zlib package, the package maintainers had to scan the repos for all copies and versions of the zlib source, patch them individually, and test each package. To make matters worse, some packages had modified versions of zlib that needed custom variants of the patch. This is a ton of work to ask of a small group of volunteers, and leaves users vulnerable for longer.
- Arnavion 2y ago
  Vendored copies of libraries is a special case that's unrelated to this discussion. This discussion is about a distro whose packages dynamically link to the distro's zlib package vs a distro whose packages statically link to the distro's zlib package.
  - consteval 2y ago
    I don't think vendored copies are a special case or unrelated. For example, Debian does not allow vendored copies of libs. You have to use the version provided by the system, even if it's out of date or not the one you prefer. This explicit disallowing of different code versions also greatly improves security and threat response. This recently (ish) bit hyprland, because they used a pinned version of wlroots, and the version of wlroots on Debian wouldn't work. And they couldn't just dynamically link to this pinned wlroots because that's still not around. If the version of wlroots in Debian, hypothetically, contains a vulnerability, then only one change is needed instead of two. I would argue if you allow static linking you implicitly encourage vendoring. I can't imagine such a distro where static linking is allowed, but there are 0 packages which use different lib commits.
- chrsig 2y ago
  > This is a ton of work to ask of a small group of volunteerss and leaves users vulnerable for longer. Perhaps consider purchasing a support contract if people's charity endangers your users.
trelane 2y ago
> A statically-linking distro would queue up those thousand packages to be rebuilt and you would receive them via OS update, just as you would with a dynamically-linking distro. The difference is just in whether you have to download 1000 updated packages or 1. That is a large difference But more significantly, you're assuming the only software installed is from the distro. This isn't what OP is talking about (unless the distro screwed up their package dependencies to get the not found error discussed. Outside the distro-provided software, you either have to rebuild them all manually or wait for the proprietary software to do it and ship you a fix.
compsciphd 2y ago
my /usr is 24G (restricting just to binary dirs, seems 18G). If every single time glibc had an update (perhaps a handful of times a year), I had to update my entire /usr (or with a bit more intelligence, just the binary packages), I'd be burning at least 100G (if not much more) of SSD life a year. in a world of SSDs that wear out, the concept of updating the entire install every single time, seems problematic.
- t-3 2y ago
  Have you ever actually worn out an SSD by compiling too much? I ran gentoo on SSDs for several years, never had an issue. If most compilation is happening in memory, updating software from source shouldn't be significantly more damaging to drives than binary patching?

singron 2y ago

The build time is pretty significant actually. E.g. NixOS takes this to the extreme and always rebuilds packages if their dependencies change. It can take days to rebuild affected packages, and you typically can't easily update in the meantime. This is worse if the rebuild breaks something since someone will have to fix or revert that before it can succeed. For non-security updates, they can do the rebuild in a branch (staging) so it's non-blocking, but you will feel the pain on a security update. In practice, users will apply a config mitigation if available or "graft" executables against an updated lib using system.replaceDependencies, which basically search and replaced the built artifacts to use a different file path.

Arnavion 2y ago
True. I'm involved in Alpine, postmarketOS and OpenSUSE packaging and I've seen builders of the first two become noticeably slow on mass rebuilds. OpenSUSE tends to be fine, but it has a lot of builders so that's probably why.
JackSlateur 2y ago
It shall be noted that there is no need to recompile everything, when a library's patched: you only need to relink the executables and rebuild the packages Still, this requires a somewhat bigger infrastructure

robert_foss 2y ago

Security + build time isn't the issue, but security + dev/testing time is. Maintaining a secure package of zlib takes linearly more time with more versions of it used. All distros are manpower limited.

Arnavion 2y ago
There's only one version of zlib, the distro-packaged version, in the scenario of this discussion.
- CRConrad 2y ago
  As I read it, that's 100% wrong: Isn't the discussion precisely about using the distro-packaged version vs. having other versions statically linked?

throw0101c 2y ago

> That's not a difference of security, only of download size (*). It is a difference of security, because now when there's an issue with (e.g.) OpenSSL, instead of just the OpenSSL distro package team having to worry about it, the MySQL distro package team has to, the Postgres distro package team, Nginx, Apache, cURL, OpenSSH, etc. All of those teams have to coordinate to release at the same time.

Arnavion 2y ago
We're talking about distro packages, not upstream software releases.
- throw0101c 2y ago
  > We're talking about distro packages, not upstream software releases. Yes, by "the MySQL package team" I meant the MySQL distro package team. Edited to clarify. But even if applied to the upstream team that releases from (e.g.) repo.mysql.org or repo.postgres.org it would apply: they're now worrying about all their dependencies as well their own code, instead of just specifying in the .deb or .rpm file "I need libssl3" and letting the OS take care of it. It would become a huge duplication of effort to keep up on security updates. At $JOB we have a general policy to always use the distro-supplied version of a package whenever possible, as if we compile it on our own and put it into /usr/local or /opt, we now have to babysit that code for security and such ourselves instead of 'outsourcing' it to the distro. Ain't nobody got time for that.

ndiddy 2y ago

It is a difference of security. As one example, Debian used to be more lenient on allowing packages to vendor and statically link libraries. Around 20 years ago, an important zlib vulnerability was found that could be exploited through malicious compressed data. Rather than just pushing out a fixed zlib package, the package maintainers had to scan the repos for all copies and versions of the zlib source, patch them individually, and test each package. To make matters worse, some packages had modified versions of zlib that needed custom variants of the patch. This is a ton of work to ask of a small group of volunteers, and leaves users vulnerable for longer.

Arnavion 2y ago
Vendored copies of libraries is a special case that's unrelated to this discussion. This discussion is about a distro whose packages dynamically link to the distro's zlib package vs a distro whose packages statically link to the distro's zlib package.
- consteval 2y ago
  I don't think vendored copies are a special case or unrelated. For example, Debian does not allow vendored copies of libs. You have to use the version provided by the system, even if it's out of date or not the one you prefer. This explicit disallowing of different code versions also greatly improves security and threat response. This recently (ish) bit hyprland, because they used a pinned version of wlroots, and the version of wlroots on Debian wouldn't work. And they couldn't just dynamically link to this pinned wlroots because that's still not around. If the version of wlroots in Debian, hypothetically, contains a vulnerability, then only one change is needed instead of two. I would argue if you allow static linking you implicitly encourage vendoring. I can't imagine such a distro where static linking is allowed, but there are 0 packages which use different lib commits.
chrsig 2y ago
> This is a ton of work to ask of a small group of volunteerss and leaves users vulnerable for longer. Perhaps consider purchasing a support contract if people's charity endangers your users.

trelane 2y ago

> A statically-linking distro would queue up those thousand packages to be rebuilt and you would receive them via OS update, just as you would with a dynamically-linking distro. The difference is just in whether you have to download 1000 updated packages or 1. That is a large difference But more significantly, you're assuming the only software installed is from the distro. This isn't what OP is talking about (unless the distro screwed up their package dependencies to get the not found error discussed. Outside the distro-provided software, you either have to rebuild them all manually or wait for the proprietary software to do it and ship you a fix.

compsciphd 2y ago

my /usr is 24G (restricting just to binary dirs, seems 18G). If every single time glibc had an update (perhaps a handful of times a year), I had to update my entire /usr (or with a bit more intelligence, just the binary packages), I'd be burning at least 100G (if not much more) of SSD life a year. in a world of SSDs that wear out, the concept of updating the entire install every single time, seems problematic.

t-3 2y ago
Have you ever actually worn out an SSD by compiling too much? I ran gentoo on SSDs for several years, never had an issue. If most compilation is happening in memory, updating software from source shouldn't be significantly more damaging to drives than binary patching?