[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Feb 2017 09:10:23 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: Re: MITRE is adding data intake to its CVE ID process
On Thu, 09 Feb 2017 at 00:00:09 -0500, cve-assign@...re.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
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.
