+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
