Re: An interesting data point

["kseifried@redhat.com" <kseifried@redhat.com>]

On 2017-12-04 11:05 PM, jericho wrote:
> 
> : > #1 2017-1000186 doesn't appear to be in there, yet is a DWF 
> assignment.
> : > Makes me think that your original mail applies to this sheet 
> only. Makes
> : > me wonder what the status codes for prior assignments would look 
> like, in
> : > a summary as you originally provided. That said, this sheet, 
> along with
> : > the original mail, still doesn't give me the info needed to 
> answer my
> : > question about 1000186.
> : 
> : You can check the git history and the spreadsheet history for info 
> on 1000186.
> 
> https://github.com/distributedweaknessfiling/DWF-CVE-Database/commits/master/2017/1000xxx/CVE-2017-1000186.json
> 
> Pretty JSON and "cleanup", basically unhelpful commit messages. 
> Taking the 
> time to go through them, there is no indication this request was 
> analyzed 
> at all. 

In general no, CVE is a claims based system, that was decided some time
ago on a board call (I don't think you were on the call, or any call
ever?) and then confirmed later via email for those not attending the
calls. If the claim looks legit, it gets a CVE.

> 
> And "go through the sheet history"? I find it odd that after all the 
> talk 
> and work done, even via an automation sub-group, that your suggestion 
> is 
> to go through a Google sheet history. Worse, you apparently don't 
> realize 
> that anonymous viewers cannot see the revision history of a Google 
> sheet. 
> That option is greyed out for us, so that is not a solution at all 
> (see 
> attached screenshot).
That's my fault, I thought the view history was more public, but you
need edit/ownership of the sheet to see the history.

> 
> Is this really the CVE assignment history process we're encouraging? 
> I ask 
> about 2017-1000186 because this is a recent example of a bad 
> assignment, 
> and a cursory analysis of it should give you or anyone else the same 
> conclusion. This, and other recent DWF assignments, haven't been 
> brought 
> up because the last time I did so (via opening Issues on the DWF 
> GitHub 
> project) received an equally negative reaction that makes *me* not 
> want to 
> work to improve the assignments. Imagine what the regular CVE 
> consumer 
> would face if they wanted to. 

I would point out you can contact the original requester, their email is
in the CVE.

> 
> Now, consider your response to me asking about a single DWF 
> assignment is 
> "read a Sheet history you can't access" and "read the commits which 
> give 
> no information pertinent to your question". After opening issues the 
> last 
> time, this makes two separate times where your proposed solution 
> doesn't 
> work for a CVE board member familiar with this process, and simply is 
> not 
> viable for the average CVE consumer. Sincerely, and I have said this 
> many 
> times on this list over the years, our actions as CVE board members 
> cannot 
> be about us only. We are on the board to represent CVE consumers and 
> give 
> input to the processes as they benefit the community and the entire 
> CVE 
> ecosystem.

Honestly I'm not going to make a ton of effort to please you. If you
have a problem with that CVE, the data is all public, if it's not a
vulnerable or there is a specific problem, please let me know, ideally
via pull requeast (e.g. provide the fixed data). While I appreciate you
keeping an eye on CVEs and trying to ensure their correctness I'm more
concerned about actually scaling CVE out and up, and running experiments
to see what works and what doesn't (and will data quality sometimes?
yes. will we fix it? sure, especially if you submit the corrected data).


> 
> : > #2 Line 211/212, can you assign these ASAP? Hanno reached out to 
> me
> : > earlier today, frustrated at the time it has taken to get an 
> assignment
> : > for WolfSSL, as his intended multi-vendor disclosure date looms 
> closer.
> : > Please respond to him directly.
> : 
> : Uh. 2 comments: one I told him to write better descriptions/etc. 
> and 
> : leave them as a comment. Secondly: this sheet is public.
> : 
> : "Please note that the contents of this form are made PUBLIC at 
> : https://pending-requests.distributedweaknessfiling.org/ and anyone 
> can 
> : add comments. "
> : 
> : so .. a disclosure date.. er... ok then.
> 
> Just relaying a message from an unhappy CVE consumer that felt 
> reaching 
> out to me for help was what he saw as the best altnerative, after not 
> getting an assignment from DWF or MITRE. He didn't mention your reply 
> to 
> him regarding the description, but it makes me wonder why we have 
> different criteria for requesting a CVE via DWF and MITRE. Not sure 
> who 
> can speak to that, but it seems like a problem to me. 
> 
> Either way, in case he didn't tell you, this is part of a 
> multi-vendor 
> assignment that involves at least two other CNAs and several other 
> non-CNA 
> vendors. So respectfully, please try to find a few minutes to reply 
> to him 
> today and see if you two can figure out how to get him the WolfSSL 
> assignment(s) in the interest of making this as coordinated a 
> disclosure 
> as possible.
> 
> Regarding your 2nd comment, would you like me to add a comment to the 
> sheet saying "fix the column widths to make this readable" after your 
> proposed "solution" below?
> 
> : > #3 I get that the sheet makes export and CSV manipulation easy, 
> but would
> : > someone expand the columns to make this more easily readable to 
> humans, or
> : > give me permission so I can do it? =)
> : 
> : Nope. You can download/make a copy if needed.
> 
> For a sheet that will be updated hours/days/weeks/months/years later 
> presumably... your solution to make this more readable to humans 
> while in 
> native Sheet format is for them to make a copy, each and every time 
> they 
> want to read it, and resize those columns every single time they make 
> that 
> copy?

Ahhh you misunderstand what the sheet is for. The sheet is simply a
cheap and dirty storage mechanism which also offers commenting. If you'd
like I can scope out a proper ticketing system and you can help build
it, but since I don't have the time or money to build it, you're welcome
to help.

> 
> Again, did we lose focus on the whole 'automation' bit that seemed 
> important earlier this year? What harm is there in making a one-time 
> change that is a bit more readable for humans on a public sheet? I 
> even 
> offered to do that for you.

I'm honestly kind of tired of this. I'd make a simple request: please
help rather than just complaining all the time.

> 
> There is a serious disconnect between the handful of people working 
> on 
> these CVE assignment / tracking components, and the CVE consumers, 
> who 
> this is entire ecosystem is designed for.
> 

Ok, so what do you suggest? Will you step up and become a CVE mentor and
helpt he DWF with CVE assignments?

> .b
> 

-- 

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