Daniel Shahaf wrote:
> Julian Foad wrote on Wed, 28 Aug 2019 11:41 +00:00:
>> * Drop the CVE? (steps 8, 15, 16)
>>
>> For cases that are not looking like a very high severity, we could
>> omit the CVE process and much of the formal description associated with
>> it. CVEs are a Good Thing, but they do require extra effort and we don't
>> have to do that for every vulnerability.
>>
>> Instead, on a case by case basis, we could choose to omit the CVE
>> (even drop it after initially requesting one) and summarize the issue at
>> a lesser level of detail.
>
> I don't follow. There is a distinction between "the issue has a CVE name",
> "the issue has an advisory", and "the issue's fixed is developed on private@
> [using either the security-by-obscurity process or the confidential process]".
> Which of these three do you propose to do away with?
I meant the formal CVE advisory and reporting process. Specifically:
* request a CVE (step 8)
- Not a significant burden in itself.
- Does require follow-up to report it as unused if we don't complete
the CVE filing process. (Again, not a significant burden in itself.)
- See discussion below on alternative naming.
* draft vulnerability announcement (in steps 10, 11)
- Greater detail required for a CVE advisory than we would otherwise
need.
- The burden is a combination of figuring out what the potential
impact of the bug is, and how best to describe it, and filling in the
boiler-plate parts of the template.
* announce the vulnerability (step 15 d, e)
- Significant manual work required here. Last time I did it, I also
received follow-up questions from Mitre as I didn't get the required
format exactly right.
- This step could potentially take just a few minutes if streamlined
and/or if developer is very familiar with it, but in practice took me
well over an hour, I'm sure, to figure out exactly what was required and
how to do it and the follow-up corrections, and that is just for
sub-steps 'd' and 'e'.
* add CVE number to the already committed log messages (step 16)
- Another few minutes of manual effort.
Having a name for a particular issue is certainly valuable. Happy to
consider taking a CVE name but not using the CVE process, if that is
acceptable. Is it? I feel it's not really. If not then we probably
should create our own internal name for the issue. That's what an Issue
Tracker is for. So, could we use our existing tracker somehow?
- Enable the ability to create an issue with restricted visibility. I
assume this is possible in Jira but I have a feeling we asked about this
in the past and for whatever reasons may not be something we and/or
Infra want to support.
- Open an issue with no specific reference to it being a security
issue, minimal details. Track the details in our pmc/security repository
as we do now; then transfer some/all of the details to the Jira issue
after public disclosure.
Either way, include the issue number in commit log messages, from the
start, so we don't have to go back to amend them after disclosure.
We might be concerned that filing an issue could draw more unwanted
attention than just making a commit, or that an observer seeing commits
referencing an issue with minimal details may be more likely to suspect
that the commit is a security fix than otherwise, but "security by
obscurity" always has this kind of problem. It doesn't matter, I think.
Let me amend my proposal to incorporate that last point (use an svn
issue number instead of a CVE name). What do you think?
- Julian
Received on 2019-08-29 09:17:44 CEST