Re: Upload of dtc-xen 0.5.13-1+squeeze1 in squeeze-proposed-updates
Hi,
Sorry for the delay in getting back to you on this.
On Fri, 2011-08-05 at 00:22 +0800, Thomas Goirand wrote:
> On 08/04/2011 02:55 AM, Adam D. Barratt wrote:
> > On Tue, 2011-07-26 at 21:25 +0200, Thomas Goirand wrote:
> >> -chmod 644 ${DTCXEN_ETCPATH}/*
> >> chmod 600 ${DTCXEN_ETCPATH}/dtc-xen.conf
> >> +chmod 600 /etc/dtc-xen/dtc-xen.cert.cert /etc/dtc-xen/dtc-xen.cert.csr
> >> /etc/dtc-xen/dtc-xen.cert.key
> >
> > Hmmm, should the new chmod be using ${DTCXEN_ETCPATH} here?
[...]
> Right, it would look better. But does this differs the decision of the
> release team, just on aesthetics of the patch? Shouldn't I have an
> urgent answer to this one, which is close be granted a security update?
To be honest, it was a quick comment based on looking at the diff in
isolation, before looking at the change in the context of the rest of
the package; I was largely expecting the response to be something like
"hmmm, good point, I'll fix that", but never mind.
> If that's the only remark that I'll get, then I consider it fine... :)
Sadly, now that I've had chance to look at the change in a larger
context, it's not the only comment I have.
First, the good news - removing the "chmod 644" is fine. The
introduction of the other chmod I'm afraid I have a few issues with,
such as:
- why is the CSR in /etc in the first place?
- why is the CSR being retained after the creation of the certificate?
- what in either the CSR or the .cert.cert (afaict the /public/ part of
the certificate) requires such restrictive permissions?
It turns out that whilst all of the above are interesting questions,
they're actually irrelevant in terms of this update, because the entire
chmod is pointless, unless I'm reading the postinst script incorrectly -
all of dtc-xen-cert.* appear to be regenerated unconditionally on every
package upgrade, so there will be no improperly permissioned files from
older installations which need fixing by that point.
(The unconditional regeneration of a bunch of things in the postinst
makes my head hurt a little, and I'm not convinced that all of it is
actually policy compliant, but that's a discussion for another day...)
Regards,
Adam
Reply to: