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 <[email protected]> wrote: > 2014-04-11 15:47 GMT+02:00 Tyler Riddle <[email protected]>: >> >>> >>> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
