httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: handling of security issues in alphas?
Date Sun, 09 Jan 2011 02:23:12 GMT
On 1/8/2011 8:50 AM, Stefan Fritsch wrote:
> On Saturday 08 January 2011, sf@apache.org wrote:
>> Author: sf
>> Date: Sat Jan  8 14:29:12 2011
>> New Revision: 1056713
>>
>> URL: http://svn.apache.org/viewvc?rev=1056713&view=rev
>> Log:
>> Fix a bug in authz logic merging which caused
>>         section->op == AUTHZ_LOGIC_AND
>>         auth_result == AUTHZ_DENIED_NO_USER
>>         child_result == AUTHZ_GRANTED
>> to return AUTHZ_GRANTED instead of AUTHZ_DENIED_NO_USER.
>>
>> While there, refactor the if blocks to make them a bit more
>> readable.
>>
>> Modified:
>>     httpd/httpd/trunk/CHANGES
>>     httpd/httpd/trunk/modules/aaa/mod_authz_core.c
> 
> This was broken since r964156 / 2.3.8.
> 
> Is there some agreed upon policy how to handle security issues that 
> only affect alphas and/or betas? Do we need a CVE id?
> 
> IMO: No for alphas, but maybe yes for betas?

Well, if it was a concern, it wouldn't be committed until we were
prepared to release the replacement, which is why such patches are
first discussed at the security@httpd.a.o by exclusively project
members who are willing to review security-related changes.

Since the ASF and others run alphas in production, these certainly
require appropriate handling, alpha beta or GA.

The only question is whether this represents an undisclosed and
unanticipated security flaw, or is a blatent and obvious bug in
behavior.  If it's the former, it gets a CVE.  If it's the later,
it just gets fixed.  Because the code is in the auth section does
not automatically elevate it to a 'security vulnerability'.  What
would elevate it is unexpected or inconsistent results that would
not be plainly observed by every administrator setting up this
configuration.



Mime
View raw message