[Secure-testing-team] Assigning unique identifiers (CVE?)

[Micah Anderson]

-----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-----