Currently apache 2.0 ships with mod_ldap and mod_auth_ldap (not be confused with similar mods that are in portage that are NOT part of apache itself). Those modules are designed to work with ldap to provide ldap authentication for apache. Currently the apache 2.0 branch only supports ldap and ldaps, it does not support ldap +tls. This is obviously a problem for anyone using ldap + tls and needs to be addressed. The problem is further exacerbated by the fact that TLS is now the recommended manner in which to do TLS and as of 2.3 openldap no longer even supports ldaps. While we do not yet have openldap 2.3 in portage, it IS the current stable release of openldap and I expect all our users will shortly run into this problem with apache. There is a bug on the apache bugzilla about this and can be read here: http://issues.apache.org/bugzilla/show_bug.cgi?id=31443 In summary, this has been addressed but only in the apache 2.1 code base. I attach a patch, courtesy of Seth Daniel, that compiles cleanly against apache 2.0.55 and provides tls support for mod_ldap and mod_auth_ldap now. I hope that you will add this to portage.
Created attachment 73491 [details, diff] apache2.patch-2.0.55.diff
bump. can an apache herd member reply as to whether you think this is something that you can include soon? Would it help if i added a patch for the current apache ebuild? What do you need me to do, if anything, to make this happen?
I don't see this as being something we'll add to the 2.0 line for 2 reasons: 1) It's supported in the 2.2 line, which we are going to start working on soon (no timeline yet, but it will be soon.) 2) Including a third-party patch in the tree would require us maintaining it and modifying upstream security fixes to work with the patch if there ever is a security issue with that section of code.
Understood though I think its a mistake unless you are _really_ going to get 2.2 in the tree very soon. Given how many people continue to use apache 1.x, I would have thought that a lot of our userbase will remain on 2.0 for some time, which makes this patch very relevant. The chances of this conflicting with a security patch are pretty low imo, low enough that i'd even volunteer to maintain the patchset if it conflicts. Still its your call, I can do this for my own clusters but I think our user base would benefit from it.
If you are willing to maintain the patch, we can include it, as long as you don't disappear like many devs tend to do. As far as 2.2, as soon as I finish one outside project (which I have a deadline set of Jan 28), I'll begin working on apache-2.2. I've already done some looking into it, and apache-2.2 won't be too difficult. It should be reasonable to say ebuild for it will be around well within the two months you mentioned in IRC. 2.2 isn't that much different from 2.0, and more then likely, 2.2 will be in the same slot and use the same USE-flag as 2.0. Most modules will just need to be rebuilt and they will work (there are exceptions to this - some modules use deprecated functions which have been removed in 2.2, but these are fairly rare and shouldn't be too long before they are fixed upstrem.)
(In reply to comment #5) > If you are willing to maintain the patch, we can include it, as long as you > don't disappear like many devs tend to do. I'll let that pass. > As far as 2.2, as soon as I finish one outside project (which I have a deadline > set of Jan 28), I'll begin working on apache-2.2. I've already done some > looking into it, and apache-2.2 won't be too difficult. It should be reasonable > to say ebuild for it will be around well within the two months you mentioned in > IRC. Well like I said its up to you. If you think that you're going to get apache 2.2 out fairly soon then I understand your reluctance to include the patch. I just don't see it as a problem to include and it adds what has to be considered mainline functionality now.
