>> On Tue, Sep 30, 2014 at 07:07:46AM -0500, Joe Brockmeier wrote: >> > > The security team didn't ask us to, as they did with heartbleed. I >> > > expect it's because a yum update _without_ a reboot is sufficient in >> > > this case, but maybe it's worth doing anyway.... >> > +1 >> > Do we need to file a ticket with rel-eng on this? >> >> Yeah, that's probably the best approach. Might put out a call for QA as >> well? > > I think it might be useful to actually have a process in place for how we handle things like this. > > 1) How we decide whether or not a security update merits refreshed images (both in terms of "who decides" and "what's the criteria") > 2) What the expected content of an updated image should be, which relates to the QA angle. If we're going to "hey, might as well update everything" - that may need more QA attention than a respin with just the bug fix. Maybe not. Or some where in between like "pull in all security updates" > 3) Who files the ticket with rel-eng (or if it should just be part of the rel-eng process for "when there's a security update", period, so a ticket doesn't need filing every time) Do we sign anything within the image build? If it needs packages to be signed before the image is generate etc it will need to be rel-eng. I believe most of the process to build cloud images in koji needs appropriate koji permissions/role. > 4) I *think* AMI IDs are now auto-replaced on the website - but if they aren't, then filing ticket to hand off to websites team > > The expected content/QA angle is also helpful from a "when (sadly) we can't discuss it widely in the community yet" POV. Establishes an expected norm, doesn't leave people wondering what the best course of action is and wouldn't it be helpful if we had the knowledge of $person. But sometimes things are embargoed, and so having more permanent guidance around might be a good idea. Agreed, in the case outlined above I suspect we're better limiting the update to the bare minimum to fix the related CVEs Peter _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
