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

[Nico Golde]

Hi,
* Kees Cook <kees at ubuntu.com> [2009-04-17 18:38]:
> On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote:
> > On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote:
> > > * Kees Cook <kees at alioth.debian.org> [2009-04-17 09:59]:
> > > > Author: kees
> > > > Date: 2009-04-17 01:25:52 +0000 (Fri, 17 Apr 2009)
> > > > New Revision: 11636
> > > > 
> > > > Modified:
> > > >    data/CVE/list
> > > > Log:
> > > > Sync from Ubuntu CVE tracker...
> > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner
> > > > fixed: lighttpd tunapie
> > > 
> > > Could you please switch that off again? Without prior 
> > > discussion I think such bots are not acceptable. I also 
> > > don't think that we want automatic fixed entries, this is 
> > > way to error prone. Also from what I experienced so far just 
> > > adding <unfixed> entries doesn't help that much, usually it 
> > > takes very long until someone picks that up and files a bug.
> > > 
> > > I want at least a further discussion of this until you 
> > > switch this on again. It's not that we were too lazy or to 
> > > unskilled so far to play with soap and mark fixed bugs 
> > > automatically in the tracker but as far as I can tell this 
> > > wasn't done on purpose.
> > 
> > if they submitted (semi-automated) bug reports for all of the unfixed
> > issues that they sync up, would that be sufficient to address your
> > concerns?

No. I see no difference between TODO: check and <unfixed> 
other than the knowledge of the package being in Debian. 
Adding <unfixed> is not adding any valuable research which 
you should do if you state it's unfixed.

> > i agree that auto-marking fixed issues is quite dangerous and should
> > not be done.
> 
> Sorry for not being clear on this; the commit isn't automatic.  The tool on
> our side just adds <unfixed> entries, and then we go through and clean up
> stuff that has been obviously fixed (i.e. entries that have a DSA attached
> to it, etc).

Ok

> Since we're highly time-limited, we can't always go hunting through
> Debian changelogs or the BTS to see if a specific CVE is actually fixed.

This would be as well not sufficient, reading and checking 
the code is. Sure there will always be vulnerabilities where 
this can't be done just because the fix is too complex, the 
code completely changed or for some other reason, but just 
following references and adding them.... this would make our 
work useless, this can be fully-automated but is of no real 
use.

> I had made the assumption that marking a "TODO: check" CVE 
> with a package and
> "<unfixed>" was more information than leaving it "TODO: check".  If this is
> not the case, I'm happy to just disable that part again.  I was just trying
> to find a way to sync information from our tracker into Debian's where
> Debian had no information listed.

I really appreciate your work, especially because of the 
often mentioned flame that Ubuntu is not contributing back. 
Yes, <unfixed> is more information than a TODO: check but 
imho alone not of much use and I tend to prevent it unless I 
really don't have the time and I know that other people will 
pick it up anyway (e.g. kernel issues). However as mentioned 
above my problem with <unfixed> is that most of these issues 
won't get picked up by somebody. One reason for this is 
check-new-issues, it does check issues with TODO but not 
with <unfixed>.

This maybe worth a discussion but in my personal opinion 
<unfixed> doesn't add much value without a corresponding bug 
report and research.

> We could file bugs, but then, I imagine people would be upset about
> duplicates.  I figured that a CVE that says "TODO: check" says absolutely
> nothing, and requires a triager to do a full analysis, where-as a CVE that
> has a package listed, marked "unfixed" means a triager would have to only
> examine that single package.

But unless it's firefox there shouldn't be a difference :) I 
think these are really corner-cases and in the vast majority 
we need commits that reflect good research.

> As always, I'm open to any suggestions.  I can take the package-adder out
> very easily and just go back to the old NFU-only merger.

I don't want to represent the official meaning of the 
security team, it would be nice to get other peoples opinion 
too on this, but I think we should further discuss this.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/secure-testing-commits/attachments/20090418/a10d0111/attachment.pgp>