[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
  2. We would need some sort of formatting or the text would be an incomprehensible blob. That too may break existing software.

 

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.

 

-- 

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> 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 <owner-cve-editorial-board-list@lists.mitre.org> on behalf of Kurt Seifried <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



 

--


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

Page Last Updated or Reviewed: October 04, 2017