[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Secure-testing-commits] r11636 - data/CVE



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?

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

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.

> btw, it's great that you're now pushing your nfu's to debian.  at least
> that work will now get split between the two distros, rather than
> duplicating the effort.  thanks!

Absolutely!  I've been doing it for quite a while now, actually.  I really
do want to reduce work for both teams, and this was the lowest hanging
fruit.  Next lowest was putting in <unfixed> entries where Debian still had
"TODO: check".  Not really clear on what's next, though.  :)

-Kees

-- 
Kees Cook                                            @debian.org


Reply to: