[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The CVE-10K Problem

I like seeing CVE identifiers used in publications that go to 
non-technical audiences, and I fear we'd frighten them away with hex.  I 
find the year useful, even if it's slightly out by one or two years for 
some issues.

I almost liked changing the initial identifier based on the type of issue 
(why not put all those vulnerable webapps into CVF-2007) but I think 
people would be confused because the CAN prefix mapped to CVE directly, so 
CVE-2004-2001 == CAN-2004-2001 but CVF-2007-0001 != CVE-2007-0001.

I'm pretty sure everyone implementing tools around CVE will have to make 
tool changes no matter what, so I'd much prefer us rolling over to 
CVE-2007-10000 which is a) what people will expect b) much less of a hack 
and c) gives the tools at least half a year to prepare.  I also prefer it 
since half the Red Hat tools will work just fine where we used the regexp 
C\S\S-\d+-\d+ for validity.

Red Hat itself moved from 3 digit to 4 digit advisory identifiers at the 
start of 2006 (we added several new products and we share identifiers 
between security and non-security updates).  In the end we didn't need the 
whole range in 2006, but because we started it at the start of the year we 
were able to add the leading 0 to help fix the sorting issues.

Mark
Page Last Updated or Reviewed: May 22, 2007