Florian Weimer
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
* Moritz Muehlenhoff:>> * Use the description (in [brackets]) as the unqiue identifier. The >> downside is that we still won''t have really stable identifiers for >> non-CVE issues. > > I don''t think we''ve ever changed a temporary description in brackets so > far, so that would be my preferred solution.Okay, in this case, this is probably the way to go. If we keep the text in square brackets once we switch from CVE-2006-XXXX to the real CVE name, I might even be able to automatically infer the transition of the internal identifier (used by debsecan) to the CVE ID.> Nothing is too minor for MITRE, it''s just that someone need to push it > to them. But we should track this process in SVN, e.g. with a short file > who did it, when at and at what time we pinged them etc.I doubt that the Subversion repository is best suited to this kind of task, but I''ll shut up until I can offer something better. 8-)
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
Micah Anderson wrote:> What I am most worried about right now is the number of FAKE issues that > exist in our data sources that lack much information at all. Going > through and figuring out who committed this to svn and then bugging that > person to try and remember what the issue was, is not going to be fun, > but I do think that it needs to happen before its such a monsterous task > that we don''t do it.If there''re such entries then it''s typically issues I''ve found on d-d-changes, and the relating changelog entry of the fixed package version should provide the details. Cheers, Moritz
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
Florian Weimer wrote:> We have a growing list of issues which have not yet received a proper > unique identifier (this is related to Debian bug #352965). Addressing > a few shortcomings in the current database scheme would be easier if I > had a unique identifier for *every* issue. > > There are several approaches: > > * Use the description (in [brackets]) as the unqiue identifier. The > downside is that we still won''t have really stable identifiers for > non-CVE issues.I don''t think we''ve ever changed a temporary description in brackets so far, so that would be my preferred solution.> * Assign Debian Vulnerability Names (DVNs) for issues which are too > minor/obscure for CVE, based on a simple scheme which still needs > to be developed.Nothing is too minor for MITRE, it''s just that someone need to push it to them. But we should track this process in SVN, e.g. with a short file who did it, when at and at what time we pinged them etc.> * Get MITRE to train some more Debian people on CVE assignment, and > use CVEs exclusively.Not much training required, just compile the links and references and send them, the more precise, the better. Cheers, Moritz
Moritz Muehlenhoff
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
Florian Weimer wrote:> * Moritz Muehlenhoff: > > >> * Use the description (in [brackets]) as the unqiue identifier. The > >> downside is that we still won''t have really stable identifiers for > >> non-CVE issues. > > > > I don''t think we''ve ever changed a temporary description in brackets so > > far, so that would be my preferred solution. > > Okay, in this case, this is probably the way to go. If we keep the > text in square brackets once we switch from CVE-2006-XXXX to the real > CVE name, I might even be able to automatically infer the transition > of the internal identifier (used by debsecan) to the CVE ID.Good, will this database rework include support for distribution specific discards of not-affected and no-dsa? (At least in the web display) That would be great, because the web display is getting noisy.> > Nothing is too minor for MITRE, it''s just that someone need to push it > > to them. But we should track this process in SVN, e.g. with a short file > > who did it, when at and at what time we pinged them etc. > > I doubt that the Subversion repository is best suited to this kind of > task, but I''ll shut up until I can offer something better. 8-)The best solution would be if a single person volunteers to handle the backlog, keeping track of what has already been sent and pings where necessary. Cheers, Moritz
Micah Anderson
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moritz Muehlenhoff wrote:> Florian Weimer wrote: > >>We have a growing list of issues which have not yet received a proper >>unique identifier (this is related to Debian bug #352965). Addressing >>a few shortcomings in the current database scheme would be easier if I >>had a unique identifier for *every* issue. >> >>There are several approaches: >> >> * Use the description (in [brackets]) as the unqiue identifier. The >> downside is that we still won''t have really stable identifiers for >> non-CVE issues. > > > I don''t think we''ve ever changed a temporary description in brackets so > far, so that would be my preferred solution.I agree, I think this way is best when combined with pushing the FAKE issues up to Mitre to get CVE assignments.>> * Assign Debian Vulnerability Names (DVNs) for issues which are too >> minor/obscure for CVE, based on a simple scheme which still needs >> to be developed.I liked this idea, but I''m not too happy with the large number of different numbering/tracking IDs that are out there that have poor information, and I would hate to pollute these already muddy waters with our own.> Nothing is too minor for MITRE, it''s just that someone need to push it > to them. But we should track this process in SVN, e.g. with a short file > who did it, when at and at what time we pinged them etc. > > >> * Get MITRE to train some more Debian people on CVE assignment, and >> use CVEs exclusively. > > > Not much training required, just compile the links and references and > send them, the more precise, the better.I''m guessing that FW was referring to getting someone "trained" so we can have a pool of CVEs to assign for issues. This might be convenient, as following up on assignment requests can be annoying, but I think we should try and push upstream first, and when they get annoyed at all the issues that we bring to them, they''ll urge us to get a pool and facilitate this. What I am most worried about right now is the number of FAKE issues that exist in our data sources that lack much information at all. Going through and figuring out who committed this to svn and then bugging that person to try and remember what the issue was, is not going to be fun, but I do think that it needs to happen before its such a monsterous task that we don''t do it. Micah Micah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEE1Il9n4qXRzy1ioRAufxAJ9UODRwCLCt7cFYTuuIh4tyQXfakgCfTVgi 81TlONegmvw/nRAQxDjoMC0=ZTt6 -----END PGP SIGNATURE-----
Florian Weimer
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
* Moritz Muehlenhoff:>> Okay, in this case, this is probably the way to go. If we keep the >> text in square brackets once we switch from CVE-2006-XXXX to the real >> CVE name, I might even be able to automatically infer the transition >> of the internal identifier (used by debsecan) to the CVE ID. > > Good, will this database rework include support for distribution specific > discards of not-affected and no-dsa? (At least in the web display) > That would be great, because the web display is getting noisy.Yes, this should be possible to implement. In the existing framework, this is rather difficult (or it would involve code duplication between the SQL and Python parts).> The best solution would be if a single person volunteers to handle the > backlog, keeping track of what has already been sent and pings > where necessary.Uhm, this requires network access, which is a bit scarce for me right now. I''ll concentrate on the infrastructure stuff. Maybe later, once I''ve moved closer to my workplace.
Florian Weimer
2006-Mar-13 12:28 UTC
[Secure-testing-team] Assigning unique identifiers (CVE?)
We have a growing list of issues which have not yet received a proper unique identifier (this is related to Debian bug #352965). Addressing a few shortcomings in the current database scheme would be easier if I had a unique identifier for *every* issue. There are several approaches: * Use the description (in [brackets]) as the unqiue identifier. The downside is that we still won''t have really stable identifiers for non-CVE issues. * Assign Debian Vulnerability Names (DVNs) for issues which are too minor/obscure for CVE, based on a simple scheme which still needs to be developed. * Get MITRE to train some more Debian people on CVE assignment, and use CVEs exclusively. * Get rid of that Subversion crap and use a real database as master source (just kidding). What do you think? Personally, I tend towards DVNs.