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