+1... Lets do it.

BTW, I would adjust #16 to include:

   Add the CVE to the CHANGES file.

That way, it's still documented in CHANGES, just after the release
is spun out, show it shows up in the next release's CHANGES.

> On May 5, 2017, at 8:39 AM, Eric Covener <cove...@gmail.com> wrote:
> (note to security@ folks -- this is a public dev@ thread!)
> Hi All.  Over the years we have tried different approaches to handling
> CVEs, varying based on who did the work, their understanding of the
> unwritten procedures, and the severity of the bug.  We haven't ever
> come to a solid consensus on some of the finer points.
> Meanwhile, there is pretty explicit foundation level guidance on this:
> https://www.apache.org/security/committers.html
> I would personally like for us to adopt the foundations process here,
> but some of the items are a departure, including having releases where
> CHANGES in the release itself reflects the fix but not the CVE#:
> Here is the change that probably has the biggest impact to the community:
> """
> ...
> The project team commits the fix. No reference should be made to the
> commit being related to a security vulnerability.
> The project team creates a release that includes the fix.
> The project team announces the release. The release announcement
> should be sent to the usual mailing lists (typically the project's
> user list, dev list, announce list and the Apache announce list).
> The project team announces the vulnerability. The vulnerability
> announcement should be sent after the release announcement to the
> following destinations:
> """
> To me, this is just a way to get us out of ambiguity/stalemate about
> the overall process and follow security@a.o's best practices.
> Thoughts?
> -- 
> Eric Covener
> cove...@gmail.com

Reply via email to