Re: Security release procedures

This is not just theoretical. The next security issue has already landed
in the queue and is currently waiting to be fixed and we have not enough
hands on deck to deal with it.

   https://www.apache.org/security/committers

After dealing with the last pair of security fixes, I feel following
that process doesn't give enough value for the extra time and effort it
takes, for cases that are not looking like a very high severity.

What could we reduce or eliminate from the process? Especially in the
private phase, as in the public phase we can more easily involve a wider
base of volunteers.

* 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.

* Drop the requirement to roll a release? (steps 12, 13, 14)

   Under present procedures, rolling a release takes special private
management procedures, and a second round of review/test/vote (after the
patch had already been reviewed and tested), as well as the usual
"paperwork" associated with a release.

   Even the commit requires a little extra thought to come up with a
commit message that obfuscates the security relevance of the fix.

   Instead we could release just the patch, initially. Then incorporate
it into a release later, in the public phase, with less extra work.
Daniel and I have some more specific ideas on how we could do that.

- Julian
Received on 2019-08-28 13:41:47 CEST