Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Feb 2017 12:25:17 -0500
From: <>
To: <>
CC: <>
Subject: Re: MITRE is adding data intake to its CVE ID process

Hash: SHA256

> C11. The X.509 certificate chain is
> incomplete.
> R11. Yes, we realize this and will be adding the missing item (Entrust
> Certification Authority - L1K) soon.

Our current maintenance schedule for resolving this is 2017-02-21 at 
2300 to 2359 UTC.

> C5. I want MITRE to send the form data, and
> the CVE ID, to the oss-security list at the same time that these are
> sent to the requester.
> R5. We have had internal discussions within MITRE about this. We are
> able to implement this easily if the community requires this approach.
> At the moment, we are expecting the requester to resend this
> information to oss-security once they accept their CVE ID assignment.

We apologize for the delayed response on this topic. The CVE Team has 
been considering deeper details of how this could be implemented. The 
advantage is that oss-security readers would obtain vulnerability 
details faster. The main disadvantage is that it would discourage some 
people from ever making CVE requests with public vulnerability 
information, and thus might make the overall information flow worse. 
The reasons it could discourage people include:

  - At the time of their CVE request, they have a rough draft that
    proves that a CVE should exist, but they haven't edited it for
    full technical accuracy and/or spelling/grammar. They do not want
    unedited text to be publicly attached to their name.

  - People sometimes rely on their request remaining non-public, and
    provide a great variety of information to us when requesting a CVE
    ID for an already-disclosed vulnerability. They would need to
    spend extra time on redactions, or MITRE would need to allocate
    staff time to assess what part of the request seems non-public,
    and redact it before making the oss-security post. Examples
    include: (A) some people provide their work email address that
    they don't ever use on public mailing lists, (B) some people
    forward email threads with personal email addresses of the
    vendor's PSIRT staff who responded to them, (C) some people
    include non-public credentials for a demo site or a download of an
    unreleased build with an experimental fix, (D) some people refer
    to embargoed vulnerabilities when clarifying that they have a new
    request that is different from related embargoed vulnerabilities.
In general, there's a common case (the requester only provides a
basic technical outline of the vulnerability and the commit URL)
where implementation is easy. There are several corner cases where
implementation is hard. The simple solution is to always ask the
requester to make their own (correctly threaded) oss-security post
that contains any or all of the response from MITRE. Until we have a
better understanding of why that simple solution is incorrect, we are
continuing to go with that simple solution. Thus far, every user (who we recognize as being an
oss-security participant) has made their own subsequent oss-security
post with at least the CVE ID. In other words, we haven't noticed a 
problem at this point. We will continue to monitor open-source requests 
for this situation and may reconsider this position if the problem 
presents itself.

One final note: if the person declines to make their own oss-security
post, this does NOT mean that the vulnerability becomes impossible to
find. The CVE Team does publish entries on for
these public vulnerabilities, and this may happen very quickly when
the requester writes the description.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


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.