[Secure-testing-team] Introducing <no-dsa>

Moritz Muehlenhoff jmm at inutil.org
Thu Jan 5 00:24:23 UTC 2006


Florian Weimer wrote:
> > Florian Weimer wrote:
> >> > [distribution-tags] - packagename <no-dsa> (This explains, why there is no DSA)
> >> 
> >> I'm wondering if this is the correct format.  Wouldn't it make sense
> >> to generate a web page for http://www.debian.org/security/ from this
> >> data?  If yes, you might want to have a bit more space for
> >> explanations than that.
> >
> > At a later stage this could be used to generate 
> > http://www.debian.org/security/nonvulns-sarge and the like, yes. These
> > explanations are also only a single line. If there's the need for a
> > more verbose form the bug should cover it anyway.
> 
> Oh, maybe we should tweak the syntax so that a reference to a bug
> report can be included.

I guess the free-form should be sufficient, if available the bug number
can be mentioned. And it should still be available on the overview page
for the sid entry. And for some cases no information is available in a
bug report. E.g. for the commited phpbb case the phpbb maintainers
contacted the security team before a bug was filed.
 
> > This would be an example:
> > CVE-2005-4357 (Cross-site scripting (XSS) vulnerability in phpBB 2.0.18, when ...)
> > 	[sarge] - phpbb2 <no-dsa> (Affects only a config option that is inherently insecure)
> 
> Okay, I've added something to the parser.  The information is not
> really included in vulnerability calculations, yet.  I'm not really
> sure how to handle this in debsecan.

Maybe leave it as unfixed, but add a note that the security team does not
intent to issue a fix for it? In most cases the severity of issues graded
as no-dsa should to be downgraded to unimportant anyway.
 
> > So, maybe debsecan could list these issues as "unfixed for a reason"? Or you
> > simply leave them as unfixed, but please ensure that the Python lib doesn't
> > choke about the new syntax element.
> 
> Sure, please give it a try.

Done.

Cheers,
        Moritz 




More information about the Secure-testing-team mailing list