from the ought-to-be-enough-for-anybody dept.
Common Vulnerabilities and Exposures (CVE) is a standard identifier for referencing known security vulnerabilities in the information security world. The identifiers are broadly used in security products such as vulnerability scanners, providing a convenient way of cross-referencing data between various tools and databases. For most of its existence, the CVE Identifier for any given vulnerability has been in the format CVE-YYYY-NNNN, where YYYY is the year the identifier was assigned, and NNNN is an incrementing fixed-width number that restarts every year.
Because the time is fast approaching where there will be more than 10,000 CVE Identifiers assigned in a year, the CVE Identifier syntax has been updated to support variable-length numbers which is likely to pose a problem for applications which have not been updated to permit more than 4 digits in the identifier. The change was adopted in July of last year, taking effect on January 1, 2014.
Personally, it sometimes feels to me that CVE identifiers are being wasted on silly things like esoteric mobile apps, but I concede that running out of numbers is an inevitability regardless of the editorial stance of the CVE Editorial Board.
(Score: 3, Funny) by fadrian on Friday September 19 2014, @11:04PM
Call the COBOL programmers!!!
That is all.
(Score: 3, Interesting) by martyb on Saturday September 20 2014, @12:34AM
For most of its existence, the CVE Identifier for any given vulnerability has been in the format CVE-YYYY-NNNN, where YYYY is the year the identifier was assigned, and NNNN is an incrementing fixed-width number that restarts every year.
I have little doubt this was considered by the powers that be, but I found it an interesting thought experiment.
What if we changed the radix to hexadecimal? So, we'd not have a 4-digit, fixed-width [hexadecimal] number. which can take on 65536 [decimal] values: 0x0000..0xFFFF. At 366 days per year (worst case = leap year) that could support up to 179.55 vulnerabilities per day, or approximately 7.5 vulnerabilities per hour.
Granted, code that expects a *decimal* number might have some issues with hex values, so it's not a drop-in-replacement. Still, I'd think it an easier transformation than supporting a variable width field. Especially considering when these are stored in a database whose schema defined this with a fixed-width field.
If that is not seem sufficient, one can always step up to base 36 where you'd have these 'digits':
That provides 36 * 36 * 36 * 36 = 1679616 values or enough room for over 1.27 vulnerabilities per minute. If that's not enough room, I think we'll have greater problems at hand that we would be wanting to deal with! =)
Wit is intellect, dancing.
(Score: 1) by Qzukk on Saturday September 20 2014, @01:59AM
Makes sense to me, we could start with A000 to guarantee that all of the decimal numbers still come first.
Personally, since the year and number go together, I'd have just started over each year eg CVE-2014-0001
(Score: 4, Informative) by Leebert on Saturday September 20 2014, @02:03AM
They do. :) That's the problem; they're getting close to assigning 10,000 per year.
(Score: 2) by JoeMerchant on Saturday September 20 2014, @03:07AM
Funny that you bring this up on talk like a Pirate day.
There was a homeless, often drunk, man who attended city council meetings regularly. He always spoke for his full 3 minutes of allotted time whenever public comment was requested, and one night, when the issue at hand was something like the lack of padded holding cells in the county lockup, this man commented about the cells, but then used his remaining 30 seconds to remind the council of his previous suggestion to switch the property tax roll identifiers to hexadecimal, to save space.
🌻🌻 [google.com]
(Score: 2) by opinionated_science on Saturday September 20 2014, @03:27PM
Thanks for that!!! *laughing*
(Score: 0) by Anonymous Coward on Saturday September 20 2014, @01:23AM
Who thought 4 digits would be enough for the forseeable future? Didn't we learn that with 640k of memory?
(Score: 0) by Anonymous Coward on Saturday September 20 2014, @03:05PM
or IPv4 ...
(Score: 2) by q.kontinuum on Saturday September 20 2014, @06:00AM
App crashes when receiving bug ids bigger than 9999. Potential b buffer overflow
Registered IRC nick on chat.soylentnews.org: qkontinuum
(Score: 3, Interesting) by ls671 on Saturday September 20 2014, @03:45PM
Hard to believe that some programmers are still hardcoding room for only 4 digits in anything after the Y2K problem where basically, 2 digits were used. Well, I guess some never learn or they want to collect more money for upgrading their software...
I mean, I don't even hardcode phone numbers and SSN to a fixed digit length anymore.
On another topic, can we assume that the 2038 unix timestamp bug will be fixed by moving counters to 64 bits by 2038?
Everything I write is lies, including this sentence.