> 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
I think it might be useful to actually have a process in place for how we handle things
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