Date: Mon, 28 Mar 2011 20:40:39 -0400 From: Alexander Wittig <alexander@wittig.name> To: Doug Barton <dougb@FreeBSD.org> Cc: d@delphij.net, Kevin Oberman <oberman@es.net>, ports@FreeBSD.ORG, delphij@FreeBSD.ORG, umq@ueo.co.jp, Xin LI <delphij@delphij.net> Subject: Re: Unable to configure dirmngr after openldap upgrade Message-ID: <63978FF4-8727-411A-85B3-9E2E7B0C1513@wittig.name> In-Reply-To: <4D9119FB.6090604@FreeBSD.org> References: <20110328194251.9F2FE1CC0C@ptavv.es.net> <4D90F43B.7050606@delphij.net> <4D90F63F.7000901@FreeBSD.org> <4D90FB97.1020208@delphij.net> <4D9119FB.6090604@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>>>=20 >>>> It seems that libldif now referenced the fetch support, and = ironically >>>> it seem be a bug but a feature :( >>>>=20 >>>> I have decided to disable FETCH support from now on, since it's = likely >>>> to bring more problems. >>>>=20 >>>> (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). >>=20 >>> 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? >>=20 >> hmm... how do I test fetching from an ldap keyserver? >=20 > I'll save you the trouble. :) I got your latest update and tested = both scenarios myself, and the answer is that they both work. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63978FF4-8727-411A-85B3-9E2E7B0C1513>