httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Change from ad-hoc/historical security process to ASF process?
Date Fri, 05 May 2017 20:32:28 GMT
+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 <> 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:
> 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

View raw message