Re: [Secure-testing-commits] r11636 - data/CVE
On Fri, 17 Apr 2009 08:43:27 -0700 Kees Cook wrote:
> On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote:
> > i have one request to improve the process: please submit a 'NOTE' with
> > a link to the ubuntu patch whenever you issue a fix that hasn't been
> > issued by debian yet. this will help to increase the debian security
> > team's awareness of the work that has already been done, and hopefully
> > make it easier/faster to issue fixes. in fact, it would be preferable
> > to get this information during the process of preparing the patch,
> > rather than after the USN is issued.
>
> I think this would be do-able. We don't really have the best integration
> for our -security pocket when it comes to patch extraction. Right now the
> Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets
> easily confused by the -security pocket (i.e. it generate a diff against
> release, not -security origin). I have bugs open for them to get it fixed,
> so this will improve.
>
> Assuming I can generate a URL with a patch (and we'd have up to 5 patch
> URLs, depending on which of our releases were affected), the logic would
> be: if <unfixed> and patch URL exists, add NOTE:. Sounds right?
a better logic would be: if no DSA issued yet for the particular CVE
add 'NOTE: ubuntu bug <launchpad bug url>\n NOTE: ubuntu patch <patch
url>'
on second thought, i'm not sure if this information would be so useful
in the tracker. it would be more useful to transmit directly to the
debian maintainer via a new bug report or as additional information in
an existing bug report. note that this could be fairly automated: you
could retrieve the bug number from debian's secure-testing svn, and
send an automatic mail to that bug number.
> > also, would it be possible to coordinate security notices better? it
> > looks bad when one of the distros releases a fix and the other doesn't
> > get the same fix out for days or weeks (i'm not saying to delay the
> > fix, but to work more closely so both distros are ready to release at
> > the same time).
>
> For embargoed issues, this is supposed to happen already, by way of
> vendor-sec. Who all from Debian is on that list, and what are the policies
> and procedures you have in place for contacting maintainers?
>
> The recent udev thing seemed like a failure within Debian to contact
> the udev maintainer. One idea we'd had was to send email to the Debian
> maintainer for stuff we've ranked as "High" or "Critical", with something
> like "there's an embargoed issue with $pkg, please make sure you get
> details from the Debian security team."
i think embargoed issues are handled OK as is.
> For public issues, it's a pretty different arrangement. The bulk of the
> packages in the archive are "community-supported" from Ubuntu's
> perspective, so we do updates when there are volunteers to do debdiffs and
> more importantly, testing. That means we're frequently behind Debian for
> those updates, and I don't see a good way to stay up to date without people
> willing to test 4 stable releases of Ubuntu. For updates we _do_ publish,
> there is such a giant backlog of stuff to fix, we're just trying to get
> stuff out the door as fast as possible. There tends to be very little time
> between our taking an issue, testing, and publishing a fix.
>
> I'm open to ideas; this has traditionally been a tricky area to get right.
i'm more concerned about the issues where ubuntu releases a fix before
debian. during the process of preparing the fix, i would like to see
better coordination with the debian package maintainer and security team
so that they are right there with you and can get the DSA out pretty
much at the same time that you get your USN out.
thanks again for your hard work and interest on this!
mike
Reply to: