You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/01/17 16:55:56 UTC
Re: security patches and releases (was [VOTE] Release Apache httpd
2.4.0)
On 1/17/2012 6:36 AM, Jim Jagielski wrote:
>
> Bill, I am taking your advice and learning some tact, so I
> respectfully ask: "What is your major malfunction?" I am
> growing tired of you constantly complaining while doing *nothing*
> to address those self-same issues which you seem to find so
> problematic.
I respectfully answer; and change the subject line - I'm just shocked
you responded to Steffan with a w00t. That was just weird.
And further answer; the project malfunction is that we communicate
to users that security patches somehow exist in the respective
dist/httpd/patches/ tree.
I have taken specific steps to consolidate the patches directories
which were devoid of patches, steps to improve the data we collect
in our vulnerabilities database, identification of previously
unmaintained data for released branches, patch review on security@
and authoring patches, responding to patch reporters, etc etc etc.
I certainly don't do nothing to address security reports.
Whomever is committing the security patches for disclosed issues
aught to publish their patch on the same day. I've participated
over 10 years, and for 10 years published relevant patches that I
had written to patches/apply_to_rev/ branches.
It seems to me that committers today have no interest in publishing
patches to dist, therefore the concept should be declared DOA, the
patches/ tree removed, and a new mechanism for communicating security
patches to the users be created. Of course the legacy of that tree
would still persist under archive.a.o/dist/httpd/patches.
I'd propose we add a field in our oval-like xml table for the patch
svn url to be recorded as soon as it is committed to svn, provided
we are talking about a disclosed issue.
Thoughts?
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 Eric Covener <co...@gmail.com>.
> The idea behind patches is entirely sound, and I strongly disagree that the practice should stop.
> Instead, the practice should be properly formalised, with comments added to the appropriate places so that it is made obvious to committers what to do,
+1 to formalising and documenting all of this.
I'm not embarassed to admit that when i'm not blocked waiting on
review / 2nd opinion, I'm frozen on not understanding the process
(when to add security banner, when to coordinate with original
reporter, ...)
Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 17, 2012, at 11:26 AM, Graham Leggett wrote:
>
> The idea behind patches is entirely sound, and I strongly disagree that the practice should stop. Instead, the practice should be properly formalised, with comments added to the appropriate places so that it is made obvious to committers what to do, and at the same time both our opening page and our downloads page should be amended to contain links to the patches directory for the benefit of end users.
+1
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.
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 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 "William A. Rowe Jr." <wr...@rowe-clan.net>.
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?
Re: security patches and releases (was [VOTE] Release Apache httpd 2.4.0)
Posted by Graham Leggett <mi...@sharp.fm>.
On 17 Jan 2012, at 5:55 PM, William A. Rowe Jr. wrote:
> Whomever is committing the security patches for disclosed issues
> aught to publish their patch on the same day. I've participated
> over 10 years, and for 10 years published relevant patches that I
> had written to patches/apply_to_rev/ branches.
>
> It seems to me that committers today have no interest in publishing
> patches to dist, therefore the concept should be declared DOA, the
> patches/ tree removed, and a new mechanism for communicating security
> patches to the users be created. Of course the legacy of that tree
> would still persist under archive.a.o/dist/httpd/patches.
What I don't understand is how the conclusion is drawn that committers don't have an interest in publishing patches to dist, when a far more likely explanation is that nobody knew to do so.
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.
The idea behind patches is entirely sound, and I strongly disagree that the practice should stop. Instead, the practice should be properly formalised, with comments added to the appropriate places so that it is made obvious to committers what to do, and at the same time both our opening page and our downloads page should be amended to contain links to the patches directory for the benefit of end users.
Regards,
Graham
--