You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/17 18:31:11 UTC

Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

On 1/17/2012 10:26 AM, Graham Leggett wrote:
> 
> Take our opening site page at http://httpd.apache.org/, no mention of patches at all. Zoom in a little to the download page at http://httpd.apache.org/download.cgi#apache23, and still no mention of the patches directory. If our end users aren't alerted to the fact these patches exist, you can hardly expect our committers to.

I was curious too, so here's what I found across the whole site;

https://www.google.com/search?q="dist%2Fhttpd%2Fpatches"+site%3Ahttpd.apache.org&filter=0

Clearly, awareness of this area has steadily decreased.  Since our
docs team are partners in maintaining the site, these references have
obviously been deleted over time.  We all need to be aware of the same
publishing mechanism, and this one has fallen apart.

So it's a good time to work out what the right strategy is, seeing as
there is overwhelming support for 'somehow' publishing patches.

I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
files for actively (or semi-actively) maintained versions.  If there is
one patch which applies to 2.2.n < 2.2.17, and a second patch for 2.2.17
and higher, it would be easier to differentiate these all within one
directory.

This suggestion precludes publishing 'other' patches.  Is there still a
role for 3rd party contrib or other unreleased patches that individuals
homes on people.a.o doesn't fulfill?


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Jan 17, 2012 at 4:19 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Tuesday 17 January 2012, William A. Rowe Jr. wrote:
>> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It
>> seems more efficient to set these up as patches/CVE-yyyy-iiii/
>> with individual files for actively (or semi-actively) maintained
>> versions.  If there is one patch which applies to 2.2.n < 2.2.17,
>> and a second patch for 2.2.17 and higher, it would be easier to
>> differentiate these all within one directory.
>
> Sometimes there may be two or more separate CVEs that are fixed by a
> single patch. How would you map that to patches/CVE-yyyy-iiii/ ? Copy
> the patch? Add a README file to CVE-foo dir that the fix is included
> in the patch for CVE-bar?

include both CVEs in the pathname

>
> Apart from that, I don't prefer one structure over the other.



-- 
Born in Roswell... married an alien...

Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 17 January 2012, William A. Rowe Jr. wrote:
> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It
> seems more efficient to set these up as patches/CVE-yyyy-iiii/
> with individual files for actively (or semi-actively) maintained
> versions.  If there is one patch which applies to 2.2.n < 2.2.17,
> and a second patch for 2.2.17 and higher, it would be easier to
> differentiate these all within one directory.

Sometimes there may be two or more separate CVEs that are fixed by a 
single patch. How would you map that to patches/CVE-yyyy-iiii/ ? Copy 
the patch? Add a README file to CVE-foo dir that the fix is included 
in the patch for CVE-bar?

Apart from that, I don't prefer one structure over the other.

Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by "Gregg L. Smith" <gl...@gknw.net>.
On 1/17/2012 11:56 AM, Eric Covener wrote:
>> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
>> more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
>> files for actively (or semi-actively) maintained versions.  If there is
>> one patch which applies to 2.2.n<  2.2.17, and a second patch for 2.2.17
>> and higher, it would be easier to differentiate these all within one
>> directory.
> The current scheme has one benefit in that a responsible user on the
> latest release has a one-stop shop for "What do I need to add?".
>
> With the CVE as the directory, they'd have to start with some other
> resource/hint or browse through the descriptions/patches
2 cents.

I like the current way as well, know right where to look, do not have 
read something first then dig through a bunch of CVE numbers. Somewhat 
dyslexic people would be better served by the apply to vs. CVEs IMHO.



Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/17/2012 2:01 PM, Eric Covener wrote:
> On Tue, Jan 17, 2012 at 2:58 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> On 1/17/2012 1:56 PM, Eric Covener wrote:
>>>> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
>>>> more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
>>>> files for actively (or semi-actively) maintained versions.  If there is
>>>> one patch which applies to 2.2.n < 2.2.17, and a second patch for 2.2.17
>>>> and higher, it would be easier to differentiate these all within one
>>>> directory.
>>>
>>> The current scheme has one benefit in that a responsible user on the
>>> latest release has a one-stop shop for "What do I need to add?".
>>>
>>> With the CVE as the directory, they'd have to start with some other
>>> resource/hint or browse through the descriptions/patches.
>>
>> I'm not sure about that.  If I have 2.2.18, what do I apply?  If there
>> were patches in .21 how do I know they apply to me?
>>
> 
> Cross your fingers and visit three directories full of patches -- the
> farther back you stay, the more work you've got in store for you.
> 
> I don't think you're in much better shape tracking down e.g. 7 CVEs though.

Actually, I think you are (now).

  http://httpd.apache.org/security/vulnerabilities_22.html



Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by Eric Covener <co...@gmail.com>.
On Tue, Jan 17, 2012 at 2:58 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 1/17/2012 1:56 PM, Eric Covener wrote:
>>> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
>>> more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
>>> files for actively (or semi-actively) maintained versions.  If there is
>>> one patch which applies to 2.2.n < 2.2.17, and a second patch for 2.2.17
>>> and higher, it would be easier to differentiate these all within one
>>> directory.
>>
>> The current scheme has one benefit in that a responsible user on the
>> latest release has a one-stop shop for "What do I need to add?".
>>
>> With the CVE as the directory, they'd have to start with some other
>> resource/hint or browse through the descriptions/patches.
>
> I'm not sure about that.  If I have 2.2.18, what do I apply?  If there
> were patches in .21 how do I know they apply to me?
>

Cross your fingers and visit three directories full of patches -- the
farther back you stay, the more work you've got in store for you.

I don't think you're in much better shape tracking down e.g. 7 CVEs though.

Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/17/2012 1:56 PM, Eric Covener wrote:
>> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
>> more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
>> files for actively (or semi-actively) maintained versions.  If there is
>> one patch which applies to 2.2.n < 2.2.17, and a second patch for 2.2.17
>> and higher, it would be easier to differentiate these all within one
>> directory.
> 
> The current scheme has one benefit in that a responsible user on the
> latest release has a one-stop shop for "What do I need to add?".
> 
> With the CVE as the directory, they'd have to start with some other
> resource/hint or browse through the descriptions/patches.

I'm not sure about that.  If I have 2.2.18, what do I apply?  If there
were patches in .21 how do I know they apply to me?


Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by Eric Covener <co...@gmail.com>.
> I'd suggest that patches/apply_to_x.y.z/ is a clumsy notation.  It seems
> more efficient to set these up as patches/CVE-yyyy-iiii/ with individual
> files for actively (or semi-actively) maintained versions.  If there is
> one patch which applies to 2.2.n < 2.2.17, and a second patch for 2.2.17
> and higher, it would be easier to differentiate these all within one
> directory.

The current scheme has one benefit in that a responsible user on the
latest release has a one-stop shop for "What do I need to add?".

With the CVE as the directory, they'd have to start with some other
resource/hint or browse through the descriptions/patches.

Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)

Posted by Eric Covener <co...@gmail.com>.
> This suggestion precludes publishing 'other' patches.  Is there still a
> role for 3rd party contrib or other unreleased patches that individuals
> homes on people.a.o doesn't fulfill?

I think beyond userdirs on people.a.o, they can get all the visibility
they need in bugzilla as open enhancements.