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