Re: Question about APR trunk and httpd ldap modules
On 27 May 2021, at 14:45, Rainer Jung wrote: > is my understanding correct, that even httpd trunk (and then also 2.4.x) > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > So since we removed LDAP support from APR trunk, that means those modules > currently can not be build using APR trunk, neither in httpd trunk nor in > httpd 2.4.x. Correct? Correct. > Just trying to understand the current situation about APR trunk and its > implications. I have a partially finished attempt at a new API for APR called apr_ldapx, I need to dig it out. Worth moving this to APR and working on a branch there? Regards, Graham —
Re: Question about APR trunk and httpd ldap modules
On Sat, May 29, 2021 at 11:55 AM Roy T. Fielding wrote: > On May 28, 2021, at 9:59 AM, William A Rowe Jr > wrote: > > AIUI, as he remains a PMC member, the veto remains binding per Roy's > conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so > just sharing historical pointers for those raising questions, no opinion > remaining of HTTP Server PMC choices at all. But I did want to point out > that the project did choose to ignore the vastly more secure PCRE 10 > rewrite and is still stuck at PCRE 8 (although I run bleed builds all the > time of httpd trunk X apr 2 trunk X pcre 10 with no issues at all.) In > theory, if the APR project has enough maintainers (minimum 3, more + than - > votes), then apr[+util] 1.x might persist for years after a 2.0 release, if > such a release occurs. > > > The veto, like any veto, was specific to both the context at the time > (2.4.0) > and the change being made. The way to resolve it is to work together > towards either a common solution (in APR) or a narrow change (in httpd). > I think everyone shares this sentiment, although your timeline is just a bit off, this was at 2.3 alpha as we were approaching beta, as the same time as the APR project was looking forward at a version major release that hasn't occurred since then. The way to not get anything done in ten years is to claim that someone > doesn't have the right to veto a change, and then insist on having the > high ground instead of working toward anything. > You might be confused, I acknowledged the veto 10 years ago, the only thing that hasn't happened in 10 years is that the API within the APR project didn't lose its dependency on another project's header files, and the veto lives on at httpd to adopt the code the APR crew collectively and nearly unanimously threw off the boat as incomplete for a 2.0 release. I never rejected anyone's efforts to advance the exact API at httpd, and never rejected any effort anyone would bring to APR to isolate the dependency chain to APR's headers alone. But you know more than anyone that what is decided for APR is decided by APR, and this is the wrong list to discuss that side of the equation. The many of us looked to your guidance through this discussion Roy, and I accepted whatever you concluded, at both of the projects, as I think most other participants did. > Projects don't *do* things; people do, preferably while working together > within the same project. It is much harder for people to do things together > when individuals are being painted into a corner, having their concerns > disregarded, or repeatedly being attacked just because you don't agree > with one decision they made. > You. I'm taking that personally, but it's irrelevant, I'm not a PMC member here at httpd, and I haven't been in the way of any committee business for nearly 2 years. I jumped off the administration of this teetering barge a while ago to let other headstrong people pilot it and give my head and heart a break from the inanity. > I suggest that the way to fix this tiny little problem is to create a new > LDAP secure client library in httpd that has the very specific purpose > we need (call it ap_ldapsc_*) and then change httpd's current usage to > make use of that library instead. If that leads to enough energy to > eventually become a common utility on its own, then it can migrate > to a common LDAP library (not necessarily APR) at that later time. > That sounds great, I'm sure the httpd community can get behind any workable solution (and perhaps, it doesn't have to be that complex, sounds like a workable APR solution even.) In any case, a veto by the author themself of their own code is a most strange thing that's ever happened at the ASF. Likewise, the way to update to PCRE 10 is to do the work necessary for > the update, including backwards compatible shims. It would make for > a good entry/student project. > Indeed, since I also did that work almost a decade ago, it's waiting for a trivial change to configure.in - and a possible optimization since stack is off the table due to the recursive complexity of regex expansion, and we never quite settled on our thread local storage best practice. Also, to Stefan, yes I recognized your coding pattern as making it very simple to drop in a less complex client implementation than libcurl. It's just so odd that we have a client all baked out in httpd, it's called mod_proxy_http, but basically it can't be repurposed. Pretty strange, I'm glad a few committers tried to tackle serf in the first place based on that gap and subversion's needs. I look forward to seeing what/how the httpd community collectively decides to move forward, I'm liking the dialog on how to catalog the changes history.
Re: Question about APR trunk and httpd ldap modules
> On May 28, 2021, at 9:59 AM, William A Rowe Jr wrote: > > AIUI, as he remains a PMC member, the veto remains binding per Roy's > conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so just > sharing historical pointers for those raising questions, no opinion remaining > of HTTP Server PMC choices at all. But I did want to point out that the > project did choose to ignore the vastly more secure PCRE 10 rewrite and is > still stuck at PCRE 8 (although I run bleed builds all the time of httpd > trunk X apr 2 trunk X pcre 10 with no issues at all.) In theory, if the APR > project has enough maintainers (minimum 3, more + than - votes), then > apr[+util] 1.x might persist for years after a 2.0 release, if such a release > occurs. The veto, like any veto, was specific to both the context at the time (2.4.0) and the change being made. The way to resolve it is to work together towards either a common solution (in APR) or a narrow change (in httpd). The way to not get anything done in ten years is to claim that someone doesn't have the right to veto a change, and then insist on having the high ground instead of working toward anything. Projects don't *do* things; people do, preferably while working together within the same project. It is much harder for people to do things together when individuals are being painted into a corner, having their concerns disregarded, or repeatedly being attacked just because you don't agree with one decision they made. I suggest that the way to fix this tiny little problem is to create a new LDAP secure client library in httpd that has the very specific purpose we need (call it ap_ldapsc_*) and then change httpd's current usage to make use of that library instead. If that leads to enough energy to eventually become a common utility on its own, then it can migrate to a common LDAP library (not necessarily APR) at that later time. Likewise, the way to update to PCRE 10 is to do the work necessary for the update, including backwards compatible shims. It would make for a good entry/student project. Roy
Re: Question about APR trunk and httpd ldap modules
On 28/05/2021 18:17, Ruediger Pluem wrote: My personal view is that I like to see this in APR just like the DBD and Crypto stuff, but as I have no time to offer to make something happen I keep myself calm in this discussion. +1 -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.
Re: Question about APR trunk and httpd ldap modules
On Thu, May 27, 2021 at 8:42 PM William A Rowe Jr wrote: > On Thu, May 27, 2021, 07:52 Eric Covener wrote: > >> On Thu, May 27, 2021 at 8:45 AM Rainer Jung >> wrote: >> >> > is my understanding correct, that even httpd trunk (and then also 2.4.x) >> > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? >> > >> > So since we removed LDAP support from APR trunk, that means those >> > modules currently can not be build using APR trunk, neither in httpd >> > trunk nor in httpd 2.4.x. Correct? >> >> I think this is correct. This was a pretty heated/sore issue to my >> recollection. Only the removal got done. >> > > That's nearly correct. > > The port to ap_ namespace was composed and committed to httpd trunk, by > myself. And in the heat of the argument, vetoed by the obvious party, so I > reasonably promptly reverted that, without a few minor tweaks that were > still necessary across various platforms or httpd build scenarios. > Actually, sf was kind enough to perform the revert, which included the initial work and several other committer's fixes; https://svn.apache.org/viewvc?view=revision&revision=1150179 Initial vote discussion (similar to what we are having) occurred here; http://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3c4e15e51e.4090...@rowe-clan.net%3e The veto of httpd accepting the ap_ldap code from APR happened here; http://mail-archives.apache.org/mod_mbox/httpd-dev/201106.mbox/%3c4192dc1d-c0b9-42bb-b614-c3a41290f...@sharp.fm%3E AIUI, as he remains a PMC member, the veto remains binding per Roy's conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so just sharing historical pointers for those raising questions, no opinion remaining of HTTP Server PMC choices at all. But I did want to point out that the project did choose to ignore the vastly more secure PCRE 10 rewrite and is still stuck at PCRE 8 (although I run bleed builds all the time of httpd trunk X apr 2 trunk X pcre 10 with no issues at all.) In theory, if the APR project has enough maintainers (minimum 3, more + than - votes), then apr[+util] 1.x might persist for years after a 2.0 release, if such a release occurs.
Re: Question about APR trunk and httpd ldap modules
On 5/28/21 9:45 AM, Stefan Eissing wrote: > > >> Am 28.05.2021 um 03:42 schrieb William A Rowe Jr : >> >> On Thu, May 27, 2021, 07:52 Eric Covener wrote: >> On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: >> >>> is my understanding correct, that even httpd trunk (and then also 2.4.x) >>> needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? >>> >>> So since we removed LDAP support from APR trunk, that means those >>> modules currently can not be build using APR trunk, neither in httpd >>> trunk nor in httpd 2.4.x. Correct? >> >> I think this is correct. This was a pretty heated/sore issue to my >> recollection. Only the removal got done. >> >> That's nearly correct. >> >> The port to ap_ namespace was composed and committed to httpd trunk, by >> myself. And in the heat of the argument, vetoed by the obvious party, so I >> reasonably promptly reverted that, without a few minor tweaks that were >> still necessary across various platforms or httpd build scenarios. >> >> But you can find nearly all the necessary work on httpd trunk history, if >> there's a desire to ressurect the ability for httpd to survive an apr 2 >> release. It didn't matter for PCRE, so I don't know that it is a priority. >> >> Any discussion w.r.t. apr project belongs at that project, if there's a >> desire to cause some action there. Based on observations of the huge scale >> of Curl vulnerabilities (which hit us for mod_md, because that is libcurl, >> as opposed to serf or something straightforward as the letsenrypt client), >> and on some additional thoughts shared on apr about further modularizing and >> disconnecting the each-and-every-facility from core apr+util, that would be >> an interesting discussion to have. But it might have even more additional >> resistance based on today's security postures, based on dependencies of >> dependencies security history. > > When serf has reached some documentation level comparable to curl, I will > have a look. I encapsulated the curl dependency in mod_md quite well and it > should be easy to provide an alternate implementation to someone who is able > to understand serf. I hope I do not give the impression that I would stop > anyone from adding this. > > Back to the beef: > > Do I understand this correctly that we have a divergence in features between > APR and AP with APR2 losing support for something AP uses (LDAP) and AP not > willing/able/no time to add this to its code base? The first step of this discussion is where such support belongs. On APR side two things popped up back then: 1. The LDAP support was incomplete as you can see by the fact that you need to deal with LDAP library details within httpd. 2. There was some discussion if there was sufficient support by the APR community for LDAP support and especially for the needed work that evolves LDAP in APR to get to a complete support. Furthermore there were different opinions on the value of LDAP support in APR given that httpd seem to be the only consumer of this feature. As there is quite some overlap between the APR and httpd community, some people who are on both communities and who thought that this belongs to APR vetoed an import of the code from APR into httpd. On the other side the code was removed from APR trunk. As APR 2.0 is not released, LDAP support remained in APR-UTIL 1.x and even httpd trunk still works with APR-UTIL 1.x the topic stayed at this state as in practice LDAP support is still there. As said this all happened about 10 years ago and I might remember single things wrongly. For more gory details I can only point to the list archives of httpd and APR. With regards to moving this forward: It still needs to be decided where this support belongs and who will do the needed work in the respective community to make it reality. My personal view is that I like to see this in APR just like the DBD and Crypto stuff, but as I have no time to offer to make something happen I keep myself calm in this discussion. Regards Rüdiger
Re: Question about APR trunk and httpd ldap modules
> Am 28.05.2021 um 03:42 schrieb William A Rowe Jr : > > On Thu, May 27, 2021, 07:52 Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > > > is my understanding correct, that even httpd trunk (and then also 2.4.x) > > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > > > So since we removed LDAP support from APR trunk, that means those > > modules currently can not be build using APR trunk, neither in httpd > > trunk nor in httpd 2.4.x. Correct? > > I think this is correct. This was a pretty heated/sore issue to my > recollection. Only the removal got done. > > That's nearly correct. > > The port to ap_ namespace was composed and committed to httpd trunk, by > myself. And in the heat of the argument, vetoed by the obvious party, so I > reasonably promptly reverted that, without a few minor tweaks that were still > necessary across various platforms or httpd build scenarios. > > But you can find nearly all the necessary work on httpd trunk history, if > there's a desire to ressurect the ability for httpd to survive an apr 2 > release. It didn't matter for PCRE, so I don't know that it is a priority. > > Any discussion w.r.t. apr project belongs at that project, if there's a > desire to cause some action there. Based on observations of the huge scale of > Curl vulnerabilities (which hit us for mod_md, because that is libcurl, as > opposed to serf or something straightforward as the letsenrypt client), and > on some additional thoughts shared on apr about further modularizing and > disconnecting the each-and-every-facility from core apr+util, that would be > an interesting discussion to have. But it might have even more additional > resistance based on today's security postures, based on dependencies of > dependencies security history. When serf has reached some documentation level comparable to curl, I will have a look. I encapsulated the curl dependency in mod_md quite well and it should be easy to provide an alternate implementation to someone who is able to understand serf. I hope I do not give the impression that I would stop anyone from adding this. Back to the beef: Do I understand this correctly that we have a divergence in features between APR and AP with APR2 losing support for something AP uses (LDAP) and AP not willing/able/no time to add this to its code base? - Stefan
Re: Question about APR trunk and httpd ldap modules
On Thu, May 27, 2021, 07:52 Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung > wrote: > > > is my understanding correct, that even httpd trunk (and then also 2.4.x) > > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > > > So since we removed LDAP support from APR trunk, that means those > > modules currently can not be build using APR trunk, neither in httpd > > trunk nor in httpd 2.4.x. Correct? > > I think this is correct. This was a pretty heated/sore issue to my > recollection. Only the removal got done. > That's nearly correct. The port to ap_ namespace was composed and committed to httpd trunk, by myself. And in the heat of the argument, vetoed by the obvious party, so I reasonably promptly reverted that, without a few minor tweaks that were still necessary across various platforms or httpd build scenarios. But you can find nearly all the necessary work on httpd trunk history, if there's a desire to ressurect the ability for httpd to survive an apr 2 release. It didn't matter for PCRE, so I don't know that it is a priority. Any discussion w.r.t. apr project belongs at that project, if there's a desire to cause some action there. Based on observations of the huge scale of Curl vulnerabilities (which hit us for mod_md, because that is libcurl, as opposed to serf or something straightforward as the letsenrypt client), and on some additional thoughts shared on apr about further modularizing and disconnecting the each-and-every-facility from core apr+util, that would be an interesting discussion to have. But it might have even more additional resistance based on today's security postures, based on dependencies of dependencies security history.
Re: Question about APR trunk and httpd ldap modules
On 5/27/21 2:52 PM, Eric Covener wrote: > On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > >> is my understanding correct, that even httpd trunk (and then also 2.4.x) >> needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? >> >> So since we removed LDAP support from APR trunk, that means those >> modules currently can not be build using APR trunk, neither in httpd >> trunk nor in httpd 2.4.x. Correct? > > I think this is correct. This was a pretty heated/sore issue to my > recollection. Only the removal got done. This is my remembrance as well, but this discussion is nearly about 10 years old (https://lists.apache.org/thread.html/71eed505b12bfc9141cd31279e6c97c8984f371cb26342b6496a14a4%401306784907%40%3Cdev.apr.apache.org%3E). Probably worth restarting it. I guess there are two options on the table: 1. Create LDAP support within APR with an API that people can agree on. Of course people do not only need to agree, but the work of doing this would need to be done over at APR land (hopefully by several people to have maintainability). 2. Do all the LDAP stuff in httpd, which of course also requires a proposal for an architecture / API and someone doing this work. Regards Rüdiger
Re: Question about APR trunk and httpd ldap modules
On Thu, May 27, 2021 at 8:45 AM Rainer Jung wrote: > is my understanding correct, that even httpd trunk (and then also 2.4.x) > needs LDAP support in APR/APU to build mod_ldap and mod_authnz_ldap? > > So since we removed LDAP support from APR trunk, that means those > modules currently can not be build using APR trunk, neither in httpd > trunk nor in httpd 2.4.x. Correct? I think this is correct. This was a pretty heated/sore issue to my recollection. Only the removal got done.
