Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Nov 2010 15:02:21 -0500 (EST)
From: "Steven M. Christey" <>
Subject: Re: econet iovec

On Sun, 14 Nov 2010, Dan Rosenberg wrote:

> This also raises a question of whether it's worth assigning CVEs to 
> every vulnerability that was fixed by a single change in the core code. 
> I'm leaning towards "no".

This is a big can of worms CVE-wise, since there can be multiple ways to 
fix a single issue.  As a result, I've come to believe that you shouldn't 
try to define a vulnerability exclusively in terms of its fix.  In 
practice within CVE, if a single fix addresses an already-public CVE-xyz 
and a whole bunch of other things, then we (generally) keep the 
already-public CVE as is, and assign a new CVE(s) to the "bunch of other 
things" that are simultaneously addressed.

For example - in package XYZ, you might have both XSS and SQL injection, 
where the XSS is fixed by input validation (say, by ensuring that a 
numeric input is actually converted to a number).  This fix will 
inadvertently address SQL injection, but a different XSS fix - say, proper 
encoding - would not.

This is one of those areas where we can't be completely consistent in CVE, 
and the amount of available information directly affects how many CVEs get 

- Steve

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.