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. But I''d like to have this information in the tracker.> > Florian, please tell me, when you''ve added this to the Python-lib > > and debsecan, afterwards I''ll add some entries to CVE/list. > > I''m not sure how to flag this in debsecan. Could you give a few > examples how you would use this tag?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) In this case the phpbb maintainers decided that a fix is not necessary because they strongly discourage the use of that specific configuration option and it is therefore not supported, so no DSA would be issued. Other examples would be entries for non-free packages or where a fix for a minor problem would be too intrusive. 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. Cheers, Moritz
* Moritz Muehlenhoff:> 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.> 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.> 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.
* Moritz Muehlenhoff:> [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.> Florian, please tell me, when you''ve added this to the Python-lib > and debsecan, afterwards I''ll add some entries to CVE/list.I''m not sure how to flag this in debsecan. Could you give a few examples how you would use this tag?
Hi,
to use the tracker efficiently for stable and oldstable we need a new
resoluton state; <no-dsa>
It should only be used with distribution tags for security-maintained
stable releases and tracks issues, which are present in a release, but
are not considered critical enough to warrant a DSA. The syntax is
as follows:
[distribution-tags] - packagename <no-dsa> (This explains, why there is no
DSA)
It is similar to <unfixed>, but has the additional information payload
that
the user can sleep safely, even with this unfixed. Plus, it gives some more
transparency why no DSA is coming, compared to the current state where
it''s
simply left unfixed. The Security Tracker should filter them out somehow, so
that they''re somehow separated from the unfixed ones.
Florian, please tell me, when you''ve added this to the Python-lib and
debsecan,
afterwards I''ll add some entries to CVE/list.
Cheers,
Moritz
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