On 18/12/2021 22:52, Hen wrote:
I was looking at Andrew's excellent clarifications to the CVE process
language ( https://github.com/apache/www-site/pull/109 ), and one out of
scope thought I had was to add a couple of steps/substeps.
Currently it says:
"The project team commits the fix. Do not make any reference that the
commit relates to a security vulnerability."
I was wondering on stretching that out into the larger text of:
"The project creates a plan for committing the fix and reviews this
with the Security Team. Once approved, the project team commits the fix.
This commit will not make any reference that the commit relates to a
security vulnerability."
I think this has hit the nail on the head regarding a key problem: How
to educate project teams about the difficulties of navigating that fine
line between having to to commit the fix to a public repository without
giving away the fact that the commit is addressing a security vulnerability.
I don't think there is a one size fits all solution to this. Some
projects have been doing this successfully for years (decades even for
some) and we don't want to add overhead to those projects.
At the other end of the spectrum there are projects that have never
received a vulnerability report before. When a project's processes are
set up to do things in public, it is all too easy for information to
accidentally leak via a public bug report, PR or similar created in
response to a security issue.
I don't have a good solution for this.
In outline, the solution is almost certainly more input from those with
experience of handling security issues. It is the detail of how to do
that I don't have. Whether those with the necessary experience are
willing and able to volunteer the time required is a separate
question/problem.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
