-----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----- _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
