At the moment we follow the standard ASF process for handling security
vulnerabilities, https://www.apache.org/security/committers.html
This includes the following step where fixes are committed with
"obscured" commit messages prior to release:
"12. The project team commits the fix. No reference should be made to the
commit being related to a security vulnerability."
I find this deeply distateful, and poor practice, for three reasons:
a) it requires committers to lie (either by omission, or explicitly)
when describing changes in the source code history. If there were an
extremely good justification for lying, say, fixing an embargoed
Critical vulnerability which affects millions of servers, I could live
with it. But we apply this for everything, even trivial Low-severity
vulnerabilities.
b) it creates a nasty conflict for mod_h2, where Stefan is cutting
mod_h2 releases at github which he knows address vulnerabilities, but is
unable to disclose that until the time of an httpd release. So mod_h2
users have access to releases which fix undisclosed vulnerabilities for
sometimes months prior to an httpd release, but aren't given the true
information on why/whether they need to upgrade.
c) because our mirrored git history is immutable, svn revision log
message changes - which retroactively add CVE names and make the svn log
a "true" record of history, rather than one containing deliberate lies,
never make it to the git log.
My preference is that we follow the ASF process for Critical
vulnerabilities, and for anything less than Critical we use a modified
version of the ASF policy, which has instead:
12. The project team commits the fix, referencing the assigned CVE, and
then:
a. Notifies the reporter that the fix is public, and will be included
in a future release.
b. Notifies MITRE, etc etc as per 15. (e) in the ASF policy
13, 14, 15 as per ASF policy except for MITRE disclose being done earlier.
16 is now unnecessary.
This roughly reverts the httpd process to what we used prior to adopting
the Tomcat-esque policy for the whole ASF. We would have to document
this and possibly need it approved by the ASF security team.
Thoughts?
Regards, Joe
vulnerabilities, https://www.apache.org/security/committers.html
This includes the following step where fixes are committed with
"obscured" commit messages prior to release:
"12. The project team commits the fix. No reference should be made to the
commit being related to a security vulnerability."
I find this deeply distateful, and poor practice, for three reasons:
a) it requires committers to lie (either by omission, or explicitly)
when describing changes in the source code history. If there were an
extremely good justification for lying, say, fixing an embargoed
Critical vulnerability which affects millions of servers, I could live
with it. But we apply this for everything, even trivial Low-severity
vulnerabilities.
b) it creates a nasty conflict for mod_h2, where Stefan is cutting
mod_h2 releases at github which he knows address vulnerabilities, but is
unable to disclose that until the time of an httpd release. So mod_h2
users have access to releases which fix undisclosed vulnerabilities for
sometimes months prior to an httpd release, but aren't given the true
information on why/whether they need to upgrade.
c) because our mirrored git history is immutable, svn revision log
message changes - which retroactively add CVE names and make the svn log
a "true" record of history, rather than one containing deliberate lies,
never make it to the git log.
My preference is that we follow the ASF process for Critical
vulnerabilities, and for anything less than Critical we use a modified
version of the ASF policy, which has instead:
12. The project team commits the fix, referencing the assigned CVE, and
then:
a. Notifies the reporter that the fix is public, and will be included
in a future release.
b. Notifies MITRE, etc etc as per 15. (e) in the ASF policy
13, 14, 15 as per ASF policy except for MITRE disclose being done earlier.
16 is now unnecessary.
This roughly reverts the httpd process to what we used prior to adopting
the Tomcat-esque policy for the whole ASF. We would have to document
this and possibly need it approved by the ASF security team.
Thoughts?
Regards, Joe