[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"

Hi Tyler and everyone else,

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.

This is a great discussion to have, and I'm glad it's occurring. Looping in the security team is also reasonable.

I'd simply encourage everyone to continue the conversation at a calmer level and with a bit more understanding of the other perspective. I've been a Debian Developer since 2001 and a Googler since 2011; both organizations do great work and are trying to do the right thing here. Since I often wear both Debian and Google hats in my GCE work, I'm mostly taking a back seat on this particular issue, but please recognize the good intentions all around. Seemingly improper suggestions are more due to unfamiliarity than any desire to breach conventions. Especially, the reason this thread is occurring is exactly to ensure that Debian is happy with the Debian images.

As I said, I'm mostly leaving this substantive discussion to others due to my dual role, but I should point out the desire here from Google is not about covering up any vendor-specific insecurity. In fact we do have a firewall on by default blocking non-SSH inbound connections across the project boundary. It's simply about keeping our (shared!) users secure in an always-on environment when they might not even know much about Debian or sysadminning, nor have the time to focus on updates. This thread is evidence of the range of reasonable approaches, but that's Google's motivation here.

- Jimmy

Reply to: