Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Moritz Mühlenhoff <jmm@inutil.org>]

Hi,

Sorry for the late reply, busy over the holiday season.

On Mon, Dec 18, 2017 at 12:12:08PM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote:
> > unattended-upgrades are not an appropriate default. It's okay for a desktop
> > system which gets powered down daily, so you can add it to tasksel lists for
> > desktop roles, but not enable it by default for servers.
> 
> I think it's not really useful for GNOME since it already has the required
> plumbing to install updates when you shut down.

Even more reason not to enable it if desktops are already catered for.

> > - It does not handle restarts. If you upgrade OpenSSL (or any library) with
> > it, all your services will be left vulnerable until restarted. It will
> > give people a warm fuzzy feeling, but not any actual security benefit.
> 
> Right, there are cases where a service restart is required. There are also
> many cases where it's not at all required because the library is only used
> by short-lived processes. And there are security updates of applications
> too. In all those cases, there are security benefits.

But it also provides a completely false sense of security as in "Debian takes
care of this by default, no need to bother".

> > - We do need to make the occasional breaking change where people have to
> > modify configuration settings or perform additional manual steps. With
> > unattended-upgrades people don't have a chance to intervene. And if their
> > setups break, we're the ones who get blamed.
> 
> If this is a real concern, we can maybe have some environment variable
> indicating that the upgrade is automatic without any human watching it and
> have the preinst fail?
> 
> Or we could have a way to tag such breaking upgrades and teach
> unattended-upgrades to skip them? And the unattended upgrades would notify
> the admin about the need to manually upgrade?

Possibly, yes.

> In any case, I'm not convinced that not installing updates and keeping a
> running vulnerable service is better than breaking the service and letting
> the admin fix it. If the admin is really concerned with the occasional
> breakage then he will use another process and deinstall
> unattended-upgrades.

unattended-upgrades is a crude hack at best, it's _not_ suitable for a default
installation. There might be scenarios where it's fine to apply (e.g.
in some test/staging environment or a desktop where breakage is acceptable and
where people can install unattended-upgrades), but not for Debian installations
per se.

It also totally changes the dynamics from "Debian releases updates and it's
my responsibility to test and deploy them within the parameters of my setup"
to "updates are installed by default and the inevitable random regression 
broke our systems, it's Debian's fault".

Providing security support for the biggest distro on a volunteer basis
is complex enough, no need for unattended-upgrades to interfere further.

> > Why was this change made without contacting team@security.debian.org (as
> > the ones who are affected the most)?
> 
> Because it was largely discussed on debian-devel already and I was not
> aware that the security team had any reservation about this. I would
> rather that we keep going and improve where needed instead of reverting
> the change.

Random mailing discussions are not a useful consensus building mechanism,
most of us don't follow them on a timely basis. This primarily affects the
Security Team and such changes need to be brought to the attention of
team@security.debian.org

Cheers,
        Moritz