[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: An interesting data point
: > #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