Re: [Secure-testing-commits] r11636 - data/CVE
On Sat, 18 Apr 2009 17:01:36 +0200Nico Golde wrote:
> * Kees Cook [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 [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.
i also don't want to speak for the entire debian security team, but i
think that what is really needed is bug reports (at least for your
traiged unembargoed issues). this is the only way that the package
maintainer gets made aware of security issues (changes to the security
tracker are not automatically conveyed to maintainers), and the
maintainers are primarily responsible for making the necessary fixes.
hence, i think the following would be a good process for ubuntu
security triagers:
1. triage issue in ubuntu
2. check status of CVE in debian (debsecan could be used for this)
3. submit bug report to launchpad (with link to debian bug report if
it already exists)
4. update ubuntu security tracker
5. if no existing debian report, submit bug to bugs.debian.org (note
that bin/report-vuln in secure-testing svn makes this semi-automated),
and preferably include a link to the launchpad report so the debian
maintainer can make use of your existing work
6. wait for email from the debian bts with bug # and update
data/CVE/list with this info
as for embargoed issues, i think that they are currently handled
reasonably well (at least from what i see on the outside), and i
wouldn't suggest changing the process (except to make sure someone
takes responsiblity on debian's side when members are known to be on
vacation).
mike
Reply to: