Re: CVEs with no REF URL (or a REF URL that is self referential)

["kseifried@redhat.com" <kseifried@redhat.com>]

On 2017-10-04 11:44 AM, Landfield, Kent wrote:
> The only two issues I have with this proposal are:
> 
>  
> 
>  1. A great deal of software out there expecting the previously
>     mandatory URL may break.

Hence using the CVE URL itself

>  2. We would need some sort of formatting or the text would be an
>     incomprehensible blob. That too may break existing software. 

Line breaks and whitespace would be enough for now. If people can't
handle line breaks and whitespace, well, yikes.

> 
>  
> 
> We need to address the core problem here of assuring software 
> developers
> keep up with our potential changes in CVE. We need to figure out how 
> to
> make this a workable, repeatable process.

Agreed. Hence my pushing for some sort of schedule/cadence and
announcement process.



> 
>  
> 
> -- 
> 
> Kent Landfield
> 
> +1.817.637.8026
> 
> kent_landfield@mcafee.com
> 
>  
> 
>  
> 
> *From: *<owner-cve-editorial-board-list@lists.mitre.org> on behalf of
> Kurt Seifried <kseifried@redhat.com>
> *Date: *Wednesday, October 4, 2017 at 12:03 PM
> *To: *Scott Lawler <scott.lawler@lp3.com>
> *Cc: *cve-editorial-board-list 
> <cve-editorial-board-list@lists.mitre.org>
> *Subject: *Re: CVEs with no REF URL (or a REF URL that is self 
> referential)
> 
>  
> 
> I assume we'd apply the same rules we currently do to the
> description/URL. I mean basically if we're pasting the URL contents 
> into
> the CVE description then what's the problem?
> 
>  
> 
> On Wed, Oct 4, 2017 at 10:59 AM, Scott Lawler <scott.lawler@lp3.com
> <mailto:scott.lawler@lp3.com>> wrote:
> 
>     I think making the URL optional is ok.  But, what is the 
> definition
>     of "all the needed data"?    
> 
>      
> 
>     How can we quantify that sufficiently to quickly reject the items
>     without sufficient information?
> 
>      
> 
>     Can we provide sufficiently detailed guidance to cover most use
>     cases?  
> 
>      
> 
>     Scott
> 
>     
> ------------------------------------------------------------------------
> 
>     *From:*owner-cve-editorial-board-list@lists.mitre.org
>     <mailto:owner-cve-editorial-board-list@lists.mitre.org>
>     <owner-cve-editorial-board-list@lists.mitre.org
>     <mailto:owner-cve-editorial-board-list@lists.mitre.org>> on behalf
>     of Kurt Seifried <kurt@seifried.org <mailto:kurt@seifried.org>>
>     *Sent:* Wednesday, October 4, 2017 12:48:03 PM
>     *To:* cve-editorial-board-list
>     *Subject:* CVEs with no REF URL (or a REF URL that is self 
> referential)
> 
>      
> 
>     So currently CVE assignments require a URL.
> 
>      
> 
>     My proposal is that, simply put, if the CVE itself can contain all
>     the needed data why not remove the requirement for the URL. The
>     advantage of this is that for embargoed issues we can immediately
>     submit the CVE to the database without having to wait for REF 
> URL's
>     to be created. The other advantage is that the REF URL can't
>     disappear, the data is embedded directly in the CVE entry. 
> 
>      
> 
>     The common case is that in the OpenSource world we often have all
>     the information needed for a CVE assignment, specifically in the
>     form of a patch with notes, but that patch has not yet been
>     committed, and it may not be a deterministic URL once committed 
> (if
>     we knew the URL in advance we would simply put it into the REF 
> URL).
>     This is especially true for Linux kernel commits and many other
>     projects that use git. Often times as well these entities do not
>     publish a security advisory or anything beyond "here's the patch
>     commit with a note" (which is sufficient information in almost all
>     cases). 
> 
>      
> 
>     So I think simply put if the rules are changed to include a
>     statement such as:
> 
>      
> 
>     The REF URL may be omitted, or set to reference the CVE itself
>     (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-XXXXXX) 
> if
>     the description contains sufficient detail to fully explain the 
> CVE
>     (e.g. code patch information). 
> 
>      
> 
> 
>      
> 
>     -- 
> 
>     Kurt Seifried
>     kurt@seifried.org <mailto:kurt@seifried.org>
> 
> 
> 
>  
> 
> -- 
> 
> 
> Kurt Seifried -- Red Hat -- Product Security -- Cloud
> PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> Red Hat Product Security contact: secalert@redhat.com
> <mailto:secalert@redhat.com>
> 

-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com