Unable to configure dirmngr after openldap upgrade

[Alexander Wittig]

Am 28.03.2011 um 19:30 schrieb Doug Barton:
> On 03/28/2011 14:20, Xin LI wrote:
>> On 03/28/11 13:57, Doug Barton wrote:
>>> On 03/28/2011 13:48, Xin LI wrote:
>>>> On 03/28/11 12:42, Kevin Oberman wrote:
>>>>> Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll
>>>>> take a look at CHANGES and see if I can figure out what broke the
>>>>> inclusion of fetch(3) support if I get a bit of time.
>>>> 
>>>> It seems that libldif now referenced the fetch support, and ironically
>>>> it seem be a bug but a feature :(
>>>> 
>>>> I have decided to disable FETCH support from now on, since it's likely
>>>> to bring more problems.
>>>> 
>>>> (If you would prefer to fix the problem for this specific problem, I
>>>> think adding a '-lfetch' would be sufficient; but, it seems to be
>>>> undesirable to depend fetch(3) unconditionally for all programs that
>>>> uses openldap).
>> 
>>> I know next to nothing about how the openldap-client stuff works, so I'm
>>> sorry if these questions are silly. :) The biggest question is, does
>>> dirmngr compile after your change? The other question is that the only
>>> reason I have openldap installed at all is so that gnupg can use it to
>>> fetch keys from ldap keyservers. Will this still work when the FETCH
>>> option is no longer present?
>> 
>> hmm... how do I test fetching from an ldap keyserver?
> 
> I'll save you the trouble. :)  I got your latest update and tested both scenarios myself, and the answer is that they both work.
> 
> So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up.

Being the one who caused the FETCH OPTION to be added in the first place (see ports/145337), I'm in favor of completely disabling it unconditionally. As noted in this PR, linking openldap-client with libfetch also can introduce other ugly side effects depending on your environment. In my case, I use security/openssl from ports, but since libfetch is built against openssl from base the result is that my www/apache22 (with LDAP support) depended on two conflicting versions of OpenSSL (from base through libfetch and ports/openssl directly).

The effect of turning this off seems to be minor. Grepping around the OpenLDAP source tree, the only place where the URL fetching actually is used is to support LDIF values referenced from a URL (e.g. using "myPicture: <http://my.server/me.jpg" to load the content of me.jpg). According to RFC2849 defining the LDIF format (note 6):
"a) Implementations SHOULD support the file:// URL format.  The
contents of the referenced file are to be included verbatim
in the interpreted output of the LDIF file.
b) Implementations MAY support other URL formats.[...]"

Even without libfetch, a) will still work, while b) will not.

Note also that OpenLDAP's support for this is a very FreeBSD specific feature. The configure.in file actually states as much (it only detects FreeBSD's libfetch):
[...]
dnl Check for fetch URL support
dnl             should be extended to support other fetch URL APIs
[...]

Given these facts, I'd be surprised if any public application were to rely on this feature (since it won't work with the (de-facto standard) OpenLDAP libraries anywhere but on FreeBSD). That only leaves the possibility of breaking some homebrew code by FreeBSD users that may exist and rely on this feature.

Alexander