[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed automatic update of packages in default GCE image; was "Re: Updating images on GCE to address CVE-2014-0160"



To clarify for Debian on GCE, we'd like to have only *security*
updates enabled by default (the case when installing the
unattended-upgrades package), with information in motd and documented
elsewhere so that admins that don't want security updates can disable
them.

There's no perfect solution here since there's always the potential
that a security patch could break something for users.  However, I
believe there's a "greater good" argument to be made for keeping users
more secure by default at the expense of the rare failure.  Having
automatic security updates becomes even more important in the Cloud
scenario where users pay much less attention to the OS layer than a
typical sysadmin might that's running Debian servers at their company.

For the case of "I don't want my MySQL service restarting without my
knowledge", it's easy for an admin to add MySQL to the
Unattended-Upgrade::Package-Blacklist section of
/etc/apt/apt.conf.d/50unattended-upgrades, for example.

It'd be great to see Debian lead the way among distros of changing the
default expectation to "I get security updates automatically and
therefore don't have to spend time worrying about tracking and
applying security patches for my apps".  I don't see this as "trying
to think for our users", but more about making their OS easier to
manage and staying secure by default.


On Fri, Apr 11, 2014 at 10:30 AM, Tyler Riddle <triddle@socialflow.com> wrote:
> There has been a discussion regarding enabling the automatic updates of packages by default in the Google Compute Engine specific Debian Cloud image where no clear consensus has been formed. I have a number of concerns I would like to express:
>
> 1) This topic has been under a thread with the wrong title. It has evolved from the original purpose into a discussion about changing behavior of the default install of Debian. I've corrected this with a new thread correctly titled.
>
> 2) Debian is the universal operating system. Debian Stable doesn't change. The Debian cloud images have been anything but stable. What is being released as Debian/Wheezy cloud images is forming into a Debian derivative with a far faster release cycle than anyone who is familiar with Debian Stable would be expecting yet the labeling is still Debian.
>
> 3) The suggestions appear to be kludges to work around fundamental problems that root in #2
>
> The amount of churn on the Debian Cloud project makes it feel like participating in the Testing version of Debian - you don't know what is going to happen and have to be ready to turn on a moments notice because of upstream changes. Thats exactly what Debian Stable is supposed to prevent. I would argue that all behavior changes to a stock install should be minimized so that a Debian Stable is as predictable as possible. Enabling automatic updates is mutually exclusive to this.
>
> This type of development cycle belongs on Testing. No one is going to complain when they have to pivot immediately to deal with a problem in testing (or if they do they don't have any standing). Delivering surprises onto Debian Stable is against the spirit. Performing development work on Debian Stable is against the spirit. The argument can be made that the cloud evolves too fast to be stable. I would argue that Debian Stable should be stable, allow the users of Debian Stable to blow their feet off, and do not blow off the feet of people who are expecting Debian Stable to behave like its label.
>
>> Maybe this should be discussed with the security team?
>
> Yes please do. I would encourage a large amount of discussion around this topic. I think a very valid question to include when asking the security team if this change should be applied is to ask to what degree Debian would like to change behavior to work around vendor specific issues. Not all cloud infrastructure is insecure by default and I don't really agree that Debian should be signing up for the pain of trying to bridge that gap in GCE. As well in the future if GCE implements the ability to control network egress policies (or if that feature exists now) automatic updates could very well break for users out of the box. Exactly how do you want to break things in the future? This is why trying to think for the users is not a good idea and why Debian Stable should remain stable.
>
> Tyler
>
>
> On Apr 11, 2014, at 9:29 AM, Mathieu Parent <math.parent@gmail.com> wrote:
>
>> 2014-04-11 15:47 GMT+02:00 Tyler Riddle <triddle@socialflow.com>:
>>>
>>>>
>>>> However, given that there is no consensus on this, I am wondering what's the best way to move forward on this.
>>>>
>>>
>>> Best case: don't enable automatic updates. Specifically don't have the images perform any action that the stock OS install media will not do. In fact the goal of the Debian Cloud project should be to write the bare minimum additional integration required to support operation on the cloud so that a Debian based OS is consistent and uniform.
>>>
>>> Please do not attempt to think for users. Please do not attempt to create a cloud OS. Please coordinate with the CD and DVD image release team to learn how to test and avoid the severe mistakes that have happened with the cloud releases. Please leave Debian alone.
>>
>> Maybe this should be discussed with the security team? Having the
>> Debian cloud images insecure by default is not very good. Cloud VMs
>> are very exposed and security updates should probably be opt-out
>> rather than opt-in.
>>
>> Regards
>> --
>> Mathieu
>


Reply to: