httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: svn commit: r1432322 - in /httpd/httpd/trunk: docs/log-message-tags/next-number docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_kernel.c
Date Wed, 16 Jan 2013 07:25:58 GMT
On 11.01.2013 23:53, wrote:
> Author: minfrin
> Date: Fri Jan 11 22:53:50 2013
> New Revision: 1432322
> URL:
> Log:
> mod_ssl: Allow the SSLUserName to be used to control the username passed
> by the FakeBasicAuth option. PR52616.


> -<p>Note that this directive has no effect if the
> -<code>FakeBasicAuth</code> option is used (see <a
> -href="#ssloptions">SSLOptions</a>).</p>
> +<p>When the <code>FakeBasicAuth</code> option is enabled, this directive
> +instead controls the value of the username embedded within the basic
> +authentication header (see <a href="#ssloptions">SSLOptions</a>).</p>

This patch changes the semantics of the FakeBasicAuth option in a
non-obvious, but potentially backwards-incompatible/surprising way -
imagine an existing configuration where SSLUserName is lying around and
FakeBasicAuth is set (i.e., the former directive is ineffective /
ignored by current mod_ssl versions). If someone is upgrading, then all
of a sudden, the existing DN entries in an authn file become invalid,
and if other (non-DN-based) entries are present which happen to map to
the attribute specified with SSLUserName, cert-based authentication
might allow access which wasn't intended in the first place.

I would prefer a more explicit way of configuring this option (perhaps
an additional SSLOption which is mutually exclusive with FakeBasicAuth).
At least for the 2.4 backport, I think it's not appropriate to change
the behavior in this rather silent way.


View raw message