httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: load order dependency between mod_ldap and mod_authnz_ldap
Date Sat, 25 Jun 2011 21:24:43 GMT
On Saturday 25 June 2011, Graham Leggett wrote:
> On 06 Jun 2011, at 11:53 PM, William A. Rowe Jr. wrote:
> > I believe the entire fix may be an entry point to
> > apr_ldap_parse_uri (check your own binaries to confirm). 
> > Setting up a single entry point should be trivial, if its
> > appropriate.
> 
> This is not so, to fix this, you would need to wrap every single
> LDAP API function call[1] in an optional function, and if you did
> that, you would solve the problem that caused you to want to
> remove apr_ldap from APR in the first place, making the whole
> exercise pointless - you may as well just have fixed apr-ldap in
> place.

No, that is not correct. You only need to wrap all ap_ldap_* calls and 
make the depending modules (mod_authnz_ldap, mod_vhost_ldap, ...) link 
to the ldap libraries themselves.

> In it's current form, this change introduces module ordering bugs
> to httpd that we haven't suffered for a decade.
> 
> In addition, the autoconf build is currently broken against apr
> v1.x on MacOSX, and this is probably broken on other platforms as
> well. This introduces serious inconvenience for vendors who have
> to mess about trying to make all of this build all over again on
> all sorts of platforms.
> 
> The timing cannot be worse - an already suboptimal API plus these
> new bugs are being dumped into httpd in the final stages of trying
> to bake the final version of httpd v2.4.0, which means we will be
> stuck with this brokenness through the life of httpd v2.4.
> 
> There is no need for this move at all, as httpd works perfectly
> against APR v1.x (or did until this change). APR v2.x hasn't gone
> through any kind of stabilisation phase, never mind seen an alpha
> or beta release, and so httpd v2.4.x being compatible with
> apr-trunk at this stage is not necessary, especially seeing that
> when httpd v2.4 is released, it's API is set in stone, but APR
> v2.0's API remains in flux. Or to put it another way, the fact
> that apr_ldap is missing from apr-trunk is not a problem for httpd
> v2.4, and can be solved after httpd v2.4.

Moving the ldap_init code from mod_ldap into apr with httpd 2.2.x 
broke support for Solaris LDAP (PR 42682), which is a regression from 
2.0.x. Fixing that would require changes both in mod_ldap and in apr-
ldap. It says a lot that mod_ldap in 2.2.x does not use 
apr_ldap_init() in the way it is recommended in the documentation 
(setting secure if ldaps is wanted without client certificates). 
Because if it did, it would not work, because the apr_ldap code is 
buggy.

Doing these changes in APR 1.x in a way that does not break an 
unmodified 2.2.x mod_ldap with some LDAP library is next to 
impossible. So moving the apr_ldap stuff as ap_ldap into httpd and 
therefore making it possible to change the API is an advantage.

> I am therefore vetoing this move of apr_ldap from APR to httpd.

Please don't.

> We need to focus on getting httpd v2.4 out the door before worrying
> about some future version of APR.
> 
> [1]
> http://www-archive.mozilla.org/directory/ietf-docs/draft-ietf-ldap
> ext-ldap-c-api-05.txt

Cheers,
Stefan

Mime
View raw message