On Fri, May 18, 2018 at 11:53:42PM +0200, Cyril Brulebois wrote: Sorry for the late reply, busy and backlogged in my inbox.
> > > That's pointless until testing becomes stable and by then it's too > > > late, this needs to be disabled now. > > Do you have minutes/rationales or something that can be pointed to? > Reverting with just “security team says so” wouldn't be too good. unattended-upgrades is a crude hack at best and _not_ suitable for a default installation. There are selected scenarios where it might be useful (such as a staging or test environment), but there will always be security updates which are not sufficiently resolved by simply installing a package or which will even break installations if no additional changes are made. The only supported way to deploy a security update issued by the Debian Security Team is to follow our advisories (which will provide instructions if an update requires subsequent steps) and test it before it gets rolled out to additional machines. While we have a very low regression rate, those are inevitable to a certain extent and there's always stuff you cannot test/cover (local packages, cruft from previous releases). u-u is also very rudimentary. It doesn't support service restarts e.g., so installing an openssl update is pretty pointless as it doesn't even attempt to warn/act on library restarts. It's also very brittle, only a few days ago I had to fix a stretch system where it uninstalled virtually all KDE packages after installing the VLC update (which installed a new version of libvlccore and all went kaboom). All this crap falls back to the security team, because people think our update broke the system. Or stuff like https://lists.debian.org/debian-security/2018/05/msg00011.html u-u breaks stuff (and would even more so if installed by default on servers, where it will cause unpredictable server downtimes during restarts etc.) and Debian should not be broken by default. If userse make a concious decision to accept the consequences of unattended-upgrades, then they can install it explicitly and have to deal with the fallout, but it must not be part of a default installation. If this had been proposed to t...@security.debian.org before making the change we would have objected immediately as we are the ones primarily affected. We can't sensibly follow all the discussions/developments made in Debian, it's far too big. (And being in the security team is already so time-demanding that it leaves little for other Debian work anyway). Cheers, Moritz