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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eric Covener
(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 [hidden email]'s best practices.

Thoughts?
--
Eric Covener
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jacob Champion-2
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 [hidden email]'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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jim Jagielski
In reply to this post by Eric Covener
+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 <[hidden email]> 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 [hidden email]'s best practices.
>
> Thoughts?
> --
> Eric Covener
> [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jacob Champion-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

William A Rowe Jr
In reply to this post by Jim Jagielski
On May 5, 2017 13:32, "Jim Jagielski" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eric Covener
On Sat, May 6, 2017 at 9:17 PM, William A Rowe Jr <[hidden email]> wrote:

> On May 5, 2017 13:32, "Jim Jagielski" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eric Covener
On Mon, May 22, 2017 at 10:58 AM, Eric Covener <[hidden email]> 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
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yann Ylavic
In reply to this post by William A Rowe Jr
On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr <[hidden email]> wrote:

> On May 5, 2017 13:32, "Jim Jagielski" <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Rainer Jung-3
Am 22.05.2017 um 22:38 schrieb Yann Ylavic:

> On Sun, May 7, 2017 at 3:17 AM, William A Rowe Jr <[hidden email]> wrote:
>> On May 5, 2017 13:32, "Jim Jagielski" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 <[hidden email]> wrote:
>>> On May 5, 2017 13:32, "Jim Jagielski" <[hidden email]> 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
Loading...