2 ms·

There's no problem with shipping a static binary, except that it means that the binary must be updated specifically every time a security issue or major bug is

by dsr_ 6y ago

There's no problem with shipping a static binary, except that it means that the binary must be updated specifically every time a security issue or major bug is fixed in a dependency. For a normal major Debian package, a fix to openssl or libc or libgtk-something automatically fixes that bug in the major package as well. For a static binary, Debian has to notice the change, rebuild the static binary, and ship it out. The benefit of a distro is shared, trustable work. Increasing the workload on the distro maintainers is not great, and Debian is an all-volunteer organization, especially sensitive to that workload.

debiandev 6y ago
Correct. Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful! - It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity. - Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage - It gives the impression that the distribution is bloated.
- jancsika 6y ago
  Debian has an escape valve from its fundamental spirit-defining policies even for non-free software. And if Debian didn't have that policy wrt non-free, I could easily make a similarly general post as you did listing the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. So, why can't there be a repo for the all the vendored things, and make a policy for the maintainers there? By not having that escape valve, the pressure shoots out on the maintainers-- in this example the maintainer's work is made impossible as evidenced by the statements of the previous maintainer that it would take two fulltime devs to package this according to the current policies. So you encourage burnout on your volunteers. This also encourages passive aggressive software design criticisms. Look at the very first comment here that shifts to talking about the "maturity" of the software under discussion. I'd be willing to bet I'd see similar flip judgments on the list discussion of this-- all of which completely ignore the monstrous build systems of the two browsers that Debian ships. So apparently there's an escape valve for exactly two packages, but no policy to generalize that solution for other packages that are the most complex and therefore most likely to burnout your volunteer packagers. Keep in mind you are already on maintainer #2 for this package that still does not ship with Debian because shipping it per current policy is too burdensome. Also notice that you've got a previous maintainer on the list-- who already said this is a two-person job at least-- calling out the current maintainer for being lazy. It seems like a pretty lousy culture if the policy guidelines put policy adherence above respect for your volunteer maintainers.
  - debiandev 6y ago
    > the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. This is a false dichotomy. > By not having that escape valve Please do your research before posting. Building packages with bundled dependencies is allowed, actually. Having a handful of small files from 3rd parties bundled in few packages is relatively harmless (if they are not security critical) and allowed. Having 200 dependencies with hundreds of thousand SLOC creates a significant burden for security updates. Put security-critical code in some of dependency and the burden become big. Make the dependencies unstable and it gets worse. Now create a similar issue for many other packages doing the same and the burden becomes huge, for the whole community. > This also encourages passive aggressive software design criticisms. I would call it outspoken criticism of bad software design.
nh2 6y ago
> a fix to openssl or libc [..] automatically fixes that bug in the major package as well. For a static binary, Debian has to notice the change Because this argument is often made, I think it's worth pointing out: Just shipping a fixed dependency like `libssl.so` isn't enough to make the fix effective on the end users' machines. You also have to restart all the running executables that link in that dependency. As far as I'm aware, Debian does not handle that for you. So even if it ships that small, nice dependency-only package update via manual or unattended upgrades, your long-running nginx will still be vulnerable until you manually restart it.
- suprfsat 6y ago
  Apt occasionally prompts to restart the ssh server, so it does have some knowledge of this.
- bostik 6y ago
  And that is actually how it's supposed to work. The last thing you want is unattended-upgrades silently restarting services (read: which can fail the start bit) behind your back. If the upgrade fails to restart nginx properly, your customers won't be seeing the pages they need to. If the upgrade fails to start sshd, you have just lost access to the system(s) you would need to fix. Plus my personal favourite: if the upgrade-and-restart breaks your message broker, EVERYTHING is on fire. In most non-orchestrated, non-cloud-native environments the right way for security upgrades is to have them available, preinstalled and configured, but not yet active. What you do need is monitoring to tell you these things are waiting so you can apply them as soon as feasible. Although to be fair, once you have orchestration, robust zero-downtime rollouts and a good CI to rebuild new versions as upgrades become available... that's a different story.
  - nh2 6y ago
    > The last thing you want is unattended-upgrades silently restarting services I don't buy this argument: It makes an arbitrary distinction between software in which the fix is reflected, and software where it isn't. For example, if said upgrade breaks an on-demand job which isn't a permanently running process but invoked by your customers through nginx, your customers also won't be seeing the results they need to. If you wanted unattended-upgrades to not have its changes reflect in the system, you might as well configure it into the mode where it only notifies you, instead of installing the new version automatically.

by dsr_ 6y ago

debiandev 6y ago

Correct. Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful! - It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity. - Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage - It gives the impression that the distribution is bloated.

jancsika 6y ago
Debian has an escape valve from its fundamental spirit-defining policies even for non-free software. And if Debian didn't have that policy wrt non-free, I could easily make a similarly general post as you did listing the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. So, why can't there be a repo for the all the vendored things, and make a policy for the maintainers there? By not having that escape valve, the pressure shoots out on the maintainers-- in this example the maintainer's work is made impossible as evidenced by the statements of the previous maintainer that it would take two fulltime devs to package this according to the current policies. So you encourage burnout on your volunteers. This also encourages passive aggressive software design criticisms. Look at the very first comment here that shifts to talking about the "maturity" of the software under discussion. I'd be willing to bet I'd see similar flip judgments on the list discussion of this-- all of which completely ignore the monstrous build systems of the two browsers that Debian ships. So apparently there's an escape valve for exactly two packages, but no policy to generalize that solution for other packages that are the most complex and therefore most likely to burnout your volunteer packagers. Keep in mind you are already on maintainer #2 for this package that still does not ship with Debian because shipping it per current policy is too burdensome. Also notice that you've got a previous maintainer on the list-- who already said this is a two-person job at least-- calling out the current maintainer for being lazy. It seems like a pretty lousy culture if the policy guidelines put policy adherence above respect for your volunteer maintainers.
- debiandev 6y ago
  > the very real dangers of shipping blobs, which probably carries more weight than the dangers of vendoring you outline. This is a false dichotomy. > By not having that escape valve Please do your research before posting. Building packages with bundled dependencies is allowed, actually. Having a handful of small files from 3rd parties bundled in few packages is relatively harmless (if they are not security critical) and allowed. Having 200 dependencies with hundreds of thousand SLOC creates a significant burden for security updates. Put security-critical code in some of dependency and the burden become big. Make the dependencies unstable and it gets worse. Now create a similar issue for many other packages doing the same and the burden becomes huge, for the whole community. > This also encourages passive aggressive software design criticisms. I would call it outspoken criticism of bad software design.

nh2 6y ago

> a fix to openssl or libc [..] automatically fixes that bug in the major package as well. For a static binary, Debian has to notice the change Because this argument is often made, I think it's worth pointing out: Just shipping a fixed dependency like `libssl.so` isn't enough to make the fix effective on the end users' machines. You also have to restart all the running executables that link in that dependency. As far as I'm aware, Debian does not handle that for you. So even if it ships that small, nice dependency-only package update via manual or unattended upgrades, your long-running nginx will still be vulnerable until you manually restart it.

suprfsat 6y ago
Apt occasionally prompts to restart the ssh server, so it does have some knowledge of this.
bostik 6y ago
And that is actually how it's supposed to work. The last thing you want is unattended-upgrades silently restarting services (read: which can fail the start bit) behind your back. If the upgrade fails to restart nginx properly, your customers won't be seeing the pages they need to. If the upgrade fails to start sshd, you have just lost access to the system(s) you would need to fix. Plus my personal favourite: if the upgrade-and-restart breaks your message broker, EVERYTHING is on fire. In most non-orchestrated, non-cloud-native environments the right way for security upgrades is to have them available, preinstalled and configured, but not yet active. What you do need is monitoring to tell you these things are waiting so you can apply them as soon as feasible. Although to be fair, once you have orchestration, robust zero-downtime rollouts and a good CI to rebuild new versions as upgrades become available... that's a different story.
- nh2 6y ago
  > The last thing you want is unattended-upgrades silently restarting services I don't buy this argument: It makes an arbitrary distinction between software in which the fix is reflected, and software where it isn't. For example, if said upgrade breaks an on-demand job which isn't a permanently running process but invoked by your customers through nginx, your customers also won't be seeing the results they need to. If you wanted unattended-upgrades to not have its changes reflect in the system, you might as well configure it into the mode where it only notifies you, instead of installing the new version automatically.