Re: Change from ad-hoc/historical security process to ASF process?

2017-05-23 Thread Ruediger Pluem 


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  
>> wrote:
>>> On May 5, 2017 13:32, "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.
>>>
>>>
>>> ... 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?

2017-05-23 Thread Rainer Jung 

Am 22.05.2017 um 22:38 schrieb Yann Ylavic:

On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr  wrote:

On May 5, 2017 13:32, "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.


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

2017-05-22 Thread Yann Ylavic 
On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr  wrote:
> On May 5, 2017 13:32, "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.
>
>
> ... 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?

2017-05-22 Thread Eric Covener 
On Mon, May 22, 2017 at 10:58 AM, Eric Covener  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
cove...@gmail.com

Re: Change from ad-hoc/historical security process to ASF process?

2017-05-22 Thread Eric Covener 
On Sat, May 6, 2017 at 9:17 PM, William A Rowe Jr  wrote:
> On May 5, 2017 13:32, "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.
>
>
> ... 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?

2017-05-06 Thread William A Rowe Jr 
On May 5, 2017 13:32, "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.


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

2017-05-05 Thread Jacob Champion 

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?

2017-05-05 Thread Jim Jagielski 
+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:
> 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

Re: Change from ad-hoc/historical security process to ASF process?

2017-05-05 Thread Jacob Champion 

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