|
|
: > #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. 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). 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. 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. : > #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? 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. 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. .b
Attachment:
cve-request-form-history.png
Description: Binary data