[Openstack-devel] Bug#684452: CVE-2012-3447 unblock: nova/2012.1.1-6

[Adam D. Barratt]

On Sat, 2012-08-11 at 13:01 +0800, Thomas Goirand wrote:
> On 08/11/2012 04:41 AM, Adam D. Barratt wrote:
> > On Fri, 2012-08-10 at 14:25 +0800, Thomas Goirand wrote:
> >> Please unblock the nova package. This fixes CVE-2012-3447, which is a
> >> file injection vulnerability in the host filesystem, using a specially
> >> crafted guest image.
[...]
> >> Note that this also includes a (needed) tweak in the configuration files
> >> as per this commit:
> >> http://anonscm.debian.org/gitweb/?p=openstack/nova.git;a=commitdiff;h=4cd725c5d164484a3ddb6bf95f37fb715cb51169
> > 
> > Two questions:
> > 
> > 1) Why is there no mention of the above changes in the changelog?
> > 
> > 2) Why does "Add nova-compute.conf files to nova-compute init if exist"
> > require
[...]
> What happened is that CVE-2012-3447 was embargoed. Ghe Rivero asked me
> to take care of it
[...]
> So I did take care of it, and was expecting to see no change in our Git.
> So I did add the upstream patch for this CVE, built, then uploaded to SID.
> 
> But I was wrong, as Ghe did this commit, and didn't tell about it. He
> didn't fill debian/changelog, which is why I didn't notice it either.

Well it would have shown up in the debdiff.  But I don't think my
complaining about that any further is helpful now, so I'll leave it
there.

> Anyway, let me explain what I believe this patch does. Previously, we
> had only a single configuration file, called /etc/nova/nova.conf. But we
> changed that, and we are now using /etc/nova/nova-compute.conf also,
> which has hypervisor specific flags (for example, nova-compute-kvm will
> have libvirt_type=kvm when nova-compute-xen will have
> connection_type=xenapi).
[...]
> I believe that using --flagfile or --config-file does the exact same
> thing. --flagfile was the old option, which has been replaced by
> --config-file (and --flagfile is now deprecated). It's a good thing to
> do that, so that it matches future releases of Openstack nova.

Okay, thanks.

> Anyway, I'm deeply concerned about this CVE. A lot more than these small
> changes in the configuration files. I believe it is necessary to
> unblock, even if I can't comment as much as I should on the above
> changes. Holding the package to enter testing can be harmful to some users.

Unblocked.

> One last thing: in our Git, I have already a debian/po/es.po update. I
> didn't upload the package with it, because of the urgency=high. Was this
> the correct thing to do (eg: plan for a later upload then unblock), or
> should I have include the template update? Please give me the release
> team view on this, so I know how to handle such situation later on.

At this stage yes, the translation could have been included.  As
Christian said, it's also understandable to want to get the security
changes out of the way.

> Also, is it ok to amend the debian/changelog for this release (eg:
> 2012.1.1-6) on the next upload?

To include details of the configuration file related changes?  That
should be okay, yes; in the long term it's preferable to not having the
changes documented.

Regards,

Adam