openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote: > Kurt Zeilenga wrote: >> >> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>>> >>>> >>>>> I'm still uncertain about how configure should detect the NSS >>>>> header >>>>> files >>>>> though; they are not in any standardized location yet AFAICS. >>>>> >>>> >>>> Like with other things, I would assume the environment to be >>>> adjusted >>>> to find the right NSS prior to running configure. >>>> >>> I'm not sure I understand what you mean by "environment to be >>> adjusted" >> >> CPPFLAGS, CFLAGS, ... and PATH environmental variables. >> >>> >>> - How does openldap detect the header files for other components? >> >> autoconf is used, which uses the compiler to check if necessary >> headers are there, with the (additional to those built into the >> compiler) header path specified via CPPFLAGS. >> >> The idea here is to give the builder the freedom over which header >> directories are searched, and the order in which they are searched. > What's the usual way that openldap does this for packages installed in > non-standard locations e.g. if I want to have my own private build of > cyrus-sasl? Is it up to the user to specify > CPPFLAGS=-I/path/to/nonstd/sasl/include and > LDFLAGS=-L/path/to/nonstd/lib ? Yes. > Does openldap configure have a > --with-sasl=/path/to/nonstd/sasl option? No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more control to the builder. > > > Perhaps a better question is - how would you like it to work? I prefer that we leave the builder with as freedom as possible. > I'm assuming there must be some way specify which crypto you want to > build > openldap with - is that a configure option? Presently there is: --with-tls=[auto,openssl,gnutls] I assume we'd just add an 'nss' option to the above. However, Howard might have other things in mind. > >> >>> Note >>> that both NSPR and NSS support pkg-config >> >> Here would be to ensure that the proper pkg-config is in the PATH. >> >> Of course, pkg-config stuff gets stuff into the environment in some >> fixed order, which does take away some freedom from the builder. I >> guess the builder can always manually adjust the order (by providing >> CPPFLAGS, etc., directly) and then provide a pkg_config which does >> little. So the freedom is there, just harder to take advantage of. > The original patch - > ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - > assumes the use of pkg-config - I suppose that is not sufficient. My only concern would be whether or not pkg-config use here is specific to a particular 3rd party packaging of NSS versus something available with all installs of NSS. I'll be leaving the actual technical review of your patch to Howard or other active committers. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt Zeilenga wrote: > > On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >>> >>> >>>> I'm still uncertain about how configure should detect the NSS header >>>> files >>>> though; they are not in any standardized location yet AFAICS. >>>> >>> >>> Like with other things, I would assume the environment to be adjusted >>> to find the right NSS prior to running configure. >>> >> I'm not sure I understand what you mean by "environment to be adjusted" > > CPPFLAGS, CFLAGS, ... and PATH environmental variables. > >> >> - How does openldap detect the header files for other components? > > autoconf is used, which uses the compiler to check if necessary > headers are there, with the (additional to those built into the > compiler) header path specified via CPPFLAGS. > > The idea here is to give the builder the freedom over which header > directories are searched, and the order in which they are searched. What's the usual way that openldap does this for packages installed in non-standard locations e.g. if I want to have my own private build of cyrus-sasl? Is it up to the user to specify CPPFLAGS=-I/path/to/nonstd/sasl/include and LDFLAGS=-L/path/to/nonstd/lib ? Does openldap configure have a --with-sasl=/path/to/nonstd/sasl option? Perhaps a better question is - how would you like it to work? I'm assuming there must be some way specify which crypto you want to build openldap with - is that a configure option? > >> Note >> that both NSPR and NSS support pkg-config > > Here would be to ensure that the proper pkg-config is in the PATH. > > Of course, pkg-config stuff gets stuff into the environment in some > fixed order, which does take away some freedom from the builder. I > guess the builder can always manually adjust the order (by providing > CPPFLAGS, etc., directly) and then provide a pkg_config which does > little. So the freedom is there, just harder to take advantage of. The original patch - ftp://ftp.openldap.org/incoming/openldap-2.4.11-nss-20080911.patch - assumes the use of pkg-config - I suppose that is not sufficient. > > -- Kurt > >

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by Kurt＠OpenLDAP.org 24 Feb '09

24 Feb '09

On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote: > Kurt(a)OpenLDAP.org wrote: >> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: >> >> >>> I'm still uncertain about how configure should detect the NSS header >>> files >>> though; they are not in any standardized location yet AFAICS. >>> >> >> Like with other things, I would assume the environment to be adjusted >> to find the right NSS prior to running configure. >> > I'm not sure I understand what you mean by "environment to be > adjusted" CPPFLAGS, CFLAGS, ... and PATH environmental variables. > > - How does openldap detect the header files for other components? autoconf is used, which uses the compiler to check if necessary headers are there, with the (additional to those built into the compiler) header path specified via CPPFLAGS. The idea here is to give the builder the freedom over which header directories are searched, and the order in which they are searched. > Note > that both NSPR and NSS support pkg-config Here would be to ensure that the proper pkg-config is in the PATH. Of course, pkg-config stuff gets stuff into the environment in some fixed order, which does take away some freedom from the builder. I guess the builder can always manually adjust the order (by providing CPPFLAGS, etc., directly) and then provide a pkg_config which does little. So the freedom is there, just harder to take advantage of. -- Kurt

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by richm＠stanfordalumni.org 24 Feb '09

24 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote: > > >> I'm still uncertain about how configure should detect the NSS header >> files >> though; they are not in any standardized location yet AFAICS. >> > > Like with other things, I would assume the environment to be adjusted > to find the right NSS prior to running configure. > I'm not sure I understand what you mean by "environment to be adjusted" - How does openldap detect the header files for other components? Note that both NSPR and NSS support pkg-config > -- Kurt > > > > >

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by hyc＠symas.com 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > Wait for 2.5 to break binary compatibility. If a function is there and > is useful, people will dig it out and use it. Agreed. But we can probably fix slapd's use of ldap_int APIs. > Just like back-bdb used > (uses?) some internal Berkeley DB locking function. (Not any more...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > > Wait for 2.5 to break binary compatibility. Sure, no hurry. I'm just getting a bit confused when digging into very nested libldap stuff... > If a function is there and > is useful, people will dig it out and use it. That's probably my last concern, though :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5974) libldap not consistently using namespaces
by h.b.furuseth＠usit.uio.no 24 Feb '09

24 Feb '09

ando(a)sys-net.it writes: > Since all those functions are not meant to be exposed, I guess fixing > the (mis)use of the ldap namespace should not create issues. Wait for 2.5 to break binary compatibility. If a function is there and is useful, people will dig it out and use it. Just like back-bdb used (uses?) some internal Berkeley DB locking function. -- Hallvard

1 0

(ITS#5974) libldap not consistently using namespaces
by ando＠sys-net.it 24 Feb '09

24 Feb '09

Full_Name: Pierangelo Masarati Version: any OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There are quite a few local functions with no namespace (e.g. re_encode_request()), but what seems to be mostly incorrect is ldap namespace pollution (e.g. ldap_chase_v3referrals()). Finally, there are quite a few occurrences of ldap_int_tls_config() used outside libldap (in slapd). Since all those functions are not meant to be exposed, I guess fixing the (mis)use of the ldap namespace should not create issues. p.

1 0

(ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl can update more than one csn value in one operation, but only one can be passed to syncprov in the csn queue. Syncprov should instead pick the updated values from the modify operation. A patch that fixes this is coming. This patch depends on the ITS#5972 patch, and is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

(ITS#5972) Send newCookie sync info messages
by rein＠OpenLDAP.org 24 Feb '09

24 Feb '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When syncprov updates its local contextCSN value after some modification took place this update will not be propagated to consumers that doesn't receive the updated entry (it could fail to match the filter, or access control could prevent it). In this case, the consumer will have an old contextCSN value although its content is up to date. The provider should in this case send a newcookie sync info message to the consumer with its updated contextCSN value. A patch that implements this is coming. This patch is required for the new test058 to succeed. Rein Tollevik Basefarm AS

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs