On Thu, May 1, 2014 at 11:49 AM, James Bromberger <[email protected]> wrote: > Hi Nash, > > Thanks for the question. My standard pattern thus far (after we discussed > and confirmed this at DebConf last year) is to only keep the latest point > release of AMIs available directly. With situations where there may be > default vulnerabilities in the base AMIs (such as in Heartbleed), I think we > want to minimise anyone accidentally running an image with known weaknesses. > > I posted here on 11 Apr that due to the nature, new AMIs were generated, and > a that a week later we would remove the older ones - a short time frame, but > relatively urgent. I actually left nearly 2 weeks of transition, and then > removed public sharing from the older AMIs for a further few days before > deleting the 7.4 AMIs (superseded with 7.4a, and now further superseded by > 7.5). > > I haven't yet posted about deprecating 7.4a as there is no immediate rush - > but this reminds me that we should. I'll send that over the weekend ins a > separate email, clearly marked with an appropriate subject. Since we dont > (yet) have a security reason to replace this, we can leave a nice long > transition time before removing the older release. I'd be keen to hear how > much time you (and other users on list) think we should leave before > removing older point releases (when there isn't a known vulnerability, and > when there is). > > If you wish, you can effectively clone the AMIs into your account, and then > you can keep them for as long as you want. I'd recommend this for > production AutoScale Groups - if you have a copy of the AMI in your account > (ie; your snapshot) then they are completely under your control. This is > probably a good thing regardless of what operating system AMIs you are > using.
James, If we go by other distro standards, like Ubuntu, it seems deprecation is done with utmost care. I believe the reason for this is that these AMI IDs are generally baked into orchestration and provisioning framework templates, that might not get updated in a timely fashion, as they might required extend Q/A by their users to update to a newer AMI of the same release. I feel the these are good standards, that I have raised in the past on this list, but initially didn't push too hard for, because at the time we didn't even have a functional cloud-init, and the AMIs in general were under fairly heavy evolution, beyond just the standard distro/package updates. I also felt that we were starting with a fairly small user base, and figured it was probably better not to lock ourselves into maintaining *incomplete* AMIs. (By incomplete, I mean by example, early AMIs that might not include cloud-init.) I'll add that although it doesn't cost much to host AMIs, forcing our users who are using unmodified AMIs to clone ours, to rely on them being there, doesn't seem ideal. In the ideal world (assuming things have stabilized on the cloud tooling side) I feel that we definitely should keep AMIs available if the release it contains still gets security patches, and can effectively be brought up to current with an apt-get update/dist-upgrade. Arguably, we might want to even consider a policy allowing us to keep older EOLed AMIs available beyond their supported life. (IE: Perhaps only advertise the latest AMI in a release, but keep the older AMIs available if people already know the ID and need to use them.) Obviously there will likely be exceptional cases where an AMI gets pulled, but I'd think that it would be a pretty high barrier that even Heartbleed *might* not have crossed. Where to draw the line here is grey, but if an instance launched from the AMI is vulnerable to remote exploits before anything has been configured, then it is a likely candidate for deprecation. (e.g. - A default ssh misconfiguration that harbors a known vector of attack.) I'll add that this may be another area where discussion with Ubuntu and Amazon Linux contributors about what their formal policy is, may make sense. (It looks like on the Ubuntu side that even EOLed AMIs are kept around. Not sure on the Amazon Linux side.) I'll add that getting granular usage stats may be helpful too, in making these decisions, since the larger the userbase, the more careful we should be about deprecation. (With a potential catch-22 being that if we are too cavalier about early deprecation, we may scare off potential users and never have a large userbase.) Thanks, Brian > All OS vendors/distributions update their AMIs from time to time - and each > time this is a new AMI I on EC2. > > My aim is to ensure we get the current point release AMIs out quickly, and > give as long transition period as we think is safe. > > > > James > > > > On 30/04/2014 8:04 AM, nash wrote: >> >> It looks like you deleted the older AMIs right away. I'm curious if this >> is the normal procedure. We want to use the Debian images for production but >> need to have some wiggle room to qa test them before they go away. >> >> --nash >> >> On Apr 27, 2014 7:52 AM, "James Bromberger" <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello all, >> >> Following this weekend's release of Debian Wheezy 7.5 [1], please find >> the following AMIs now available globally in AWS EC2: >> > > Virtualisation Para-virtualisation (PVM) Hardware > Virtualisation (HVM) > > Root filesystem EBS EBS Instance store EBS > ------------------------------------------------------------------------------- > Architecture i386 x86_64 x86_64 x86_64 > US-East-1 ami-90886cf8 ami-2c886c44 ami-848a6eec ami-86896dee > US-West-1 ami-6895ad2d ami-5c95ad19 ami-d495ad91 ami-0e95ad4b > US-West-2 ami-a0760290 ami-40760270 ami-ee7703de ami-10770320 > EU-West-1 ami-510fcb26 ami-630fcb14 ami-a70fcbd0 ami-210fcb56 > AP-Southeast-1 ami-24fba876 ami-22fba870 ami-7cfaa92e ami-dcfba88e > AP-Southeast-2 ami-24fba876 ami-edc75cd7 ami-0bc65d31 ami-33c65d09 > AP-Northeast-1 ami-c7296cc6 ami-91296c90 ami-b53570b4 ami-112b6e10 > SA-East-1 ami-ffb815e2 ami-c3b815de ami-efb815f2 ami-f5b815e8 > US-Gov-West-1 > CN-North-1 - ami-c6b123ff - ami-38b62401 > >> >> > >> Please take care to update any CloudFormation templates and AutoScale >> groups to use these newer AMI IDs (or clone these updated AMIs into your >> account and use your own AMI IDs). These were generated by the current >> version of bootstrap-vz as found in github; no additional improvements were >> made over and above what landed for the impromptu 7.4a release (Console to >> hvc0, Cloudinit not testing other metadata services, S3 backed AMIs to 4 GB >> root (from 1GB), and all pending security updates until that point in time >> which for 7.4a was the heartbleed libssl fix in particular). >> >> AWS GovCloud and AWS Marketplace updates will be pushed in a few days >> should no issues arise here. >> >> For any existing instances, please pay attention to pending security >> updates (as always) with apt-get update && apt-get upgrade, and please >> consider installing the unattended-upgrades package to help keep your >> instance(s) up to date. >> >> More information is on the Wiki at >> https://wiki.debian.org/Cloud/AmazonEC2Image/Wheezy >> >> James >> [1] https://www.debian.org/News/2014/20140426 > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/cacfairyhcsd8nnuoco8ovfuoys+aduziefo8hizmtzsrxeh...@mail.gmail.com
