|
Message-ID: <CANO=Ty3S0SmpoUVj5ZiQL9RF99PL7Kxt4SpDJQt2D_1SDwQmsw@mail.gmail.com> Date: Fri, 8 Jul 2016 07:55:40 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security <oss-security@...ts.openwall.com> Cc: CVE ID Requests <cve-assign@...re.org> 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 security@....net" 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 <kaplanlior@...il.com> 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 > https://liorkaplan.wordpress.com/2016/07/07/anonymous-cve-requests/ > > 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: secalert@...hat.com
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.