Shellshocked cloud images

[Juerg Haefliger]

Hi all,

Are there any plans to build new Fedora 19 & 20 cloud images with a fixed
bash?

Thanks
...Juerg

[Matthew Miller]

On Tue, Sep 30, 2014 at 11:40:40AM +0200, Juerg Haefliger wrote:
> Are there any plans to build new Fedora 19 & 20 cloud images with a fixed
> bash?

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....

[Joe Brockmeier]

On 09/30/2014 07:04 AM, Matthew Miller wrote:
> On Tue, Sep 30, 2014 at 11:40:40AM +0200, Juerg Haefliger wrote:
> > Are there any plans to build new Fedora 19 & 20 cloud images with a fixed
> > bash?
>
> 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?

Thanks,

jzb

[Matthew Miller]

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?

[Robyn Bergeron]

----- Original Message -----
> From: "Matthew Miller" 
> To: [e-mail], "Fedora Cloud SIG" 
> Sent: Tuesday, September 30, 2014 5:27:16 AM
> Subject: Re: Shellshocked cloud images
>
> 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.
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)
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.

And this is me totally not volunteering to write it. Sorry! Just suggesting to save sanity in the long run. <3

-robyn
> --
> Matthew Miller
>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Peter Robinson]

> > 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.
> How we decide whether or not a security update merits refreshed images (both in terms of "who decides" and "what's the criteria")
> 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"
> 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.
> 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

[Matthew Miller]

On Tue, Sep 30, 2014 at 09:40:42AM -0400, Robyn Bergeron wrote:
> I think it might be useful to actually have a process in place for how we
> handle things like this.

Yes. See https://fedorahosted.org/cloud/ticket/43 and
https://fedorahosted.org/cloud/ticket/51 and 
https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Imag...