Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2016 07:55:40 -0600
From: Kurt Seifried <>
To: oss-security <>
Cc: CVE ID Requests <>
Subject: Re: On anonymous CVE assignments

I'm hoping to make this better with the DWF by including more meta data in
the CVE data (e.g. affected products/versions) which will make it much
easier to automate notification in the future (e.g. "if affected product ==
php then email" or whatever). Part of the problem is that
for an org like MITRE or the DWF to do all the coordination around security
issues (as opposed to straight up CVE assignments) is highly labor
intensive and difficult to scale.

Also if projects don't like "Surprise" CVEs one way to deal with that is to
request the CVE's themselves when they know something is a security
vulnerability. Also making it easy to contact them helps, the harder you
make it for a security researcher to deal with you, the less likely they
are to.

On Fri, Jul 8, 2016 at 7:39 AM, Lior Kaplan <> wrote:

> Hi,
> I'm sorry for sending this to the cve-assign mail, but I think this is
> important to how CVE assignment process should work and the importance of
> cooperating with the upstream projects.
> In the past year+ I've been dealing with CVE assignment and the PHP
> project. During this period we managed to work closer with the Linux
> distributions and also to improve the internal process regarding CVE
> requests.
> I've blogged about a recent problem I encountered with is request and
> assignment of CVE for issues almost a year old without any public info
> about this ("anonymous requests"). Meaning that me, being part of upstream
> (incl. the security team), don't even know we've got CVE assigned and can
> update things on our side (and also other relevant upstreams such as
> libgd).
> More details at
> I'll be happy to be referred to the right forum to further discuss this.
> Till then, I hope you'll take these remakes into consideration, so the
> whole eco system could work more smoothly.
> Kaplan
> The PHP project


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

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.