You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2017/05/05 12:39:22 UTC
Change from ad-hoc/historical security process to ASF process?
(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
covener@gmail.com
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Jacob Champion <ch...@gmail.com>.
On 05/05/2017 05:39 AM, Eric Covener wrote:
> 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.
This is the only part that makes me nervous, since I worry it'll
encourage obscure commits, but otherwise...
> 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?
...I'm +1 to adopting the standard process in its entirety. We can
always modify pieces later if they end up not working for us.
--Jacob
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Eric Covener <co...@gmail.com>.
On Mon, May 22, 2017 at 10:58 AM, Eric Covener <co...@gmail.com> wrote:
> Last chance for anyone else to speak up.
Not really "last", but before this thread is lost forever to everyones
mail archives.
--
Eric Covener
covener@gmail.com
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Eric Covener <co...@gmail.com>.
On Sat, May 6, 2017 at 9:17 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On May 5, 2017 13:32, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> +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.
>
>
> ... And if we follow through, the copy on httpd.a.o/dist/httpd/ (both 2.x
> and 2.x.y files) can be the annotated flavors. +1 from me.
Last chance for anyone else to speak up.
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/23/2017 12:26 PM, Rainer Jung wrote:
> Am 22.05.2017 um 22:38 schrieb Yann Ylavic:
>> On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>> On May 5, 2017 13:32, "Jim Jagielski" <ji...@jagunet.com> wrote:
>>>
>>> +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.
>>>
>>>
>>> ... And if we follow through, the copy on httpd.a.o/dist/httpd/ (both 2.x
>>> and 2.x.y files) can be the annotated flavors. +1 from me.
>>
>> +1 here too.
>
> I'm also +1.
+1
Regards
Rüdiger
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Rainer Jung <ra...@kippdata.de>.
Am 22.05.2017 um 22:38 schrieb Yann Ylavic:
> On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> On May 5, 2017 13:32, "Jim Jagielski" <ji...@jagunet.com> wrote:
>>
>> +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.
>>
>>
>> ... And if we follow through, the copy on httpd.a.o/dist/httpd/ (both 2.x
>> and 2.x.y files) can be the annotated flavors. +1 from me.
>
> +1 here too.
I'm also +1.
Rainer
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On May 5, 2017 13:32, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> +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.
>
>
> ... And if we follow through, the copy on httpd.a.o/dist/httpd/ (both 2.x
> and 2.x.y files) can be the annotated flavors. +1 from me.
+1 here too.
Re: Change from ad-hoc/historical security process to ASF process?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On May 5, 2017 13:32, "Jim Jagielski" <ji...@jagunet.com> wrote:
+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.
... And if we follow through, the copy on httpd.a.o/dist/httpd/ (both 2.x
and 2.x.y files) can be the annotated flavors. +1 from me.
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Jacob Champion <ch...@gmail.com>.
On 05/05/2017 01:32 PM, Jim Jagielski wrote:
> +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.
Sounds good to me.
--Jacob
Re: Change from ad-hoc/historical security process to ASF process?
Posted by Jim Jagielski <ji...@jaguNET.com>.
+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 <co...@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
> covener@gmail.com