On 1/8/2011 8:50 AM, Stefan Fritsch wrote: > On Saturday 08 January 2011, [email protected] 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 [email protected] 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.
