oss-sec mailing list archives
Re: MITRE is adding data intake to its CVE ID process
From: Simon McVittie <smcv () debian org>
Date: Thu, 9 Feb 2017 09:10:23 +0000
On Thu, 09 Feb 2017 at 00:00:09 -0500, cve-assign () mitre org wrote:
If you have had trouble using the <https://cveform.mitre.org/> site, please let us know specifically what happened and how it did not meet your expectations.
The CVE form requires specifying a vendor on the "products and sources list". I'm sure this works fine for proprietary software, where everyone obtains Microsoft Office from Microsoft. For open source it seems impractical: for instance, I'm a maintainer of both D-Bus and ikiwiki, neither of which has any particular allegiance to any larger legal entity than the individual maintainers. Once released, D-Bus is later packaged by Debian, Red Hat, etc., and ikiwiki is packaged in at least Debian and Fedora; but they are not the people issuing releases and do not have any special authority over the upstream project, so there's no particular reason why the upstream maintainers should say that any particular OS distribution is "our vendor". Or do you expect the upstream maintainers of open source software that is packaged by at least one major distribution to choose one of those distributions arbitrarily, and claim they are the vendor for the purposes of your web form? If so, please make that more clear. Similarly, I hope you're not expecting upstream open source maintainers to check that their own software is in some master list of products before requesting a CVE? I'm reasonably sure ikiwiki isn't in any non-automated list of products, but Debian issues security update notifications for it and would like to use CVE IDs in them. For situations where a vulnerability is discovered by maintainers, I've found it much easier to obtain CVE IDs before publication by asking distribution security contacts like the Debian security team (again, an arbitrary choice among the distributions that could be considered to be the vendor). However, for public vulnerabilities, I don't want to leave my users vulnerable while waiting for a CVE ID for a vulnerability that is already known to the public - so I find myself issuing security updates that identify the vulnerabilities with some self-generated identifier, and attaching a CVE reference later. It seems to me that this is the opposite of the intention of the CVE system: in an ideal world, every security update would come with a CVE ID, even if that ID is later marked as a duplicate of some other report. (In practice what I frequently end up doing is allocating OVE IDs <http://www.openwall.com/ove/> and then later declaring them to be duplicates of a newly-issued CVE, as seen on <https://ikiwiki.info/security/#index48h2>.) S
Current thread:
- MITRE is adding data intake to its CVE ID process cve-assign (Feb 08)
- Re: MITRE is adding data intake to its CVE ID process P J P (Feb 08)
- Re: MITRE is adding data intake to its CVE ID process Simon McVittie (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process Jeremy Stanley (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process Peter Bex (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process Steven R. Loomis (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process Amos Jeffries (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process Jeremy Stanley (Feb 09)
- Re: MITRE is adding data intake to its CVE ID process John Haxby (Feb 10)
- Re: MITRE is adding data intake to its CVE ID process Stiepan (Feb 10)
- Re: MITRE is adding data intake to its CVE ID process Simon McVittie (Feb 10)
- Re: MITRE is adding data intake to its CVE ID process Pierre Schweitzer (Feb 10)
- Re: MITRE is adding data intake to its CVE ID process Moritz Muehlenhoff (Feb 11)