[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Mar 2012 13:45:58 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Tim Brown <tmb@...35.com>, Mark Stanislav <mark.stanislav@...il.com>,
"Adam D. Barratt" <adam@...m-barratt.org.uk>
Subject: Re: CVE Requests
On 03/16/2012 12:37 PM, Tim Brown wrote:
> On Friday 16 Mar 2012 16:11:04 Mark Stanislav wrote:
>> All points being made are very much valid and I certainly
>> understand how contextually oss-sec may be used to allocation
>> requests under different circumstances.
>>
>> So here's my situation, I'm up for suggestions (of which, "wait
>> longer", is perfectly viable!)...
>>
>> 1) March 1st, I sent 2 of these CVEs over to Steve Christy at
>> MITRE who had previously allocated 9 prior CVEs in a day or two
>> generally 2) March 8th, after not hearing back from Steve, I
>> contacted cve@...redirectly with all 5 3) March 15th, after not
>> hearing back from MITRE, I contacted Kurt off list as I've noted
>> his helpfulness doing allocations 3a) Kurt pointed me to email
>> the list, rather than him directly (which is perfectly fine, but
>> perhaps not the context I was aiming for initially)
>
> Josh Bressers (Josh, correct me if I'm using your name in vain)
> used to be quite happy to assign CVEs for undisclosed (embargoed)
> F/OSS issues providing details were forthcoming with the request.
> If Josh is no longer able to fulfil that role due to a change of
> circumstance at Redhat it would be nice if someone stepped into the
> breach - be that Redhat, Debian or one of the other CNAs. There
> is definately a place for "disclosed to project, being/been fixed,
> not public - can I have a CVE?" without deferring to the distros
> list or MITRE - most of the time projects can respond in a timely
> fashion, so a minimum effort approach is ideal.
You may have uh noticed me assigning 200+ cve's in the last few
months. I took over for Josh. I am unwilling to public assign CVE's
that are likely to end up with duplicates (e.g. no information CVE's
already sent in as a request to Mitre).
I am quite happy to assign "secret" or whatever you want to call them
CVE's (I do it all the time on linux-distros list for embargoed
issues) but I'm also trying to avoid duplicates and other messes. If
the issue is so secret you can't even give me a version #, brief
description, etc. than chances are Mitre needs to handle it.
I'm asking for pretty basic info like version #'s affected and ideally
fixed if you got it. This doesn't need to be complicated.
http://oss-security.openwall.org/wiki/mailing-lists/distros
--
Kurt Seifried Red Hat Security Response Team (SRT)
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.
