4 ms·

> 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 ar

by 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.
kwk1 6y ago
Needrestart handles that for you: https://tracker.debian.org/pkg/needrestart https://tracker.debian.org/pkg/needrestart

by nh2 6y ago

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.

kwk1 6y ago

Needrestart handles that for you: https://tracker.debian.org/pkg/needrestart https://tracker.debian.org/pkg/needrestart