Mailing List Archive

Question about APR trunk and httpd ldap modules
Hi there,

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?

Just trying to understand the current situation about APR trunk and its
implications.

Thanks and regards,

Rainer
Re: Question about APR trunk and httpd ldap modules [ In reply to ]
On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de> 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.
Re: Question about APR trunk and httpd ldap modules [ In reply to ]
On 5/27/21 2:52 PM, Eric Covener wrote:
> On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de> 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 [ In reply to ]
On Thu, May 27, 2021, 07:52 Eric Covener <covener@gmail.com> wrote:

> On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de>
> 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 [ In reply to ]
> Am 28.05.2021 um 03:42 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
>
> On Thu, May 27, 2021, 07:52 Eric Covener <covener@gmail.com> wrote:
> On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de> 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 [ In reply to ]
On 5/28/21 9:45 AM, Stefan Eissing wrote:
>
>
>> Am 28.05.2021 um 03:42 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
>>
>> On Thu, May 27, 2021, 07:52 Eric Covener <covener@gmail.com> wrote:
>> On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de> 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 [ In reply to ]
On Thu, May 27, 2021 at 8:42 PM William A Rowe Jr <wrowe@rowe-clan.net>
wrote:

> On Thu, May 27, 2021, 07:52 Eric Covener <covener@gmail.com> wrote:
>
>> On Thu, May 27, 2021 at 8:45 AM Rainer Jung <rainer.jung@kippdata.de>
>> 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.4090700@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-C3A41290F18B@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 [ In reply to ]
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 [ In reply to ]
> On May 28, 2021, at 9:59 AM, William A Rowe Jr <wrowe@rowe-clan.net> 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 [ In reply to ]
On Sat, May 29, 2021 at 11:55 AM Roy T. Fielding <fielding@gbiv.com> wrote:

> On May 28, 2021, at 9:59 AM, William A Rowe Jr <wrowe@rowe-clan.net>
> 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 [ In reply to ]
On 27 May 2021, at 14:45, Rainer Jung <rainer.jung@kippdata.de> 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