openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#5071) ;binary issue
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 11:01 PM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > > > I've noticed an issue related to operating on certificates with/ > without ;binary, > as detailed in the table below > > slapadd filter requested attrs > > | ;binary | no ;binary | ;binary | > no ;binary > -------------+--------------+--------------+-------------- > +--------------- > ;binary | results | results | returned | returned > -------------+--------------+--------------+-------------- > +--------------- > no ;binary | no results | results | not returned | returned > > So it seems that if data is loaded with ;binary then search > operations work > regardless of having specified ;binary in search filters or in > requested > attributes, while if data is loaded without, then search operations > only work if > ;binary is omitted. RFC 4523 states that ;binary MUST be used when > transferring > certificates, so perhaps slapd should be either liberal enough to > allow any > combination, or strict enough to prevent those data types from > working without > ;binary. The bug is in allowing a certificate to be loaded without ;binary. -- Kurt

1 0

(ITS#5071) ;binary issue
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) I've noticed an issue related to operating on certificates with/without ;binary, as detailed in the table below slapadd filter requested attrs | ;binary | no ;binary | ;binary | no ;binary -------------+--------------+--------------+--------------+--------------- ;binary | results | results | returned | returned -------------+--------------+--------------+--------------+--------------- no ;binary | no results | results | not returned | returned So it seems that if data is loaded with ;binary then search operations work regardless of having specified ;binary in search filters or in requested attributes, while if data is loaded without, then search operations only work if ;binary is omitted. RFC 4523 states that ;binary MUST be used when transferring certificates, so perhaps slapd should be either liberal enough to allow any combination, or strict enough to prevent those data types from working without ;binary. p.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 10:48 PM, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The >> certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa >> and HEAD fails >> to parse it because it is an integer with length equal to 9, which >> is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c: >> 254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. >> Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means > from > 0 up to 2^31-1... This and other RFC 4511 BER restrictions do not apply to BER/DER-encoded attribute values, such as certificates. > I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self- > consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. > > 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 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

ando(a)sys-net.it wrote: > I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, > according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails > to parse it because it is an integer with length equal to 9, which is larger > than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER > encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time > to get past the sizeof(ber_int_t) limitation... ... which would violate RFC 4511 where it states that INTEGER means from 0 up to 2^31-1... I have a simple solution for this problem, at the cost of partially violating rfc 4523: if an integer is larger than 2^31-1, it could be represented in the certificateExactMatch normalization in hexadecimal form, much like OpenSSL does. This would increase interoperability with OpenSSL and be at least self-consistent, since all serialNumbers that large would be consistently expanded that way. Another solution, preserving the decimal representation, would probably require some arbitrary precision support from external libraries. If there's consensus, I'd post my simple patch. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails to parse it because it is an integer with length equal to 9, which is larger than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time to get past the sizeof(ber_int_t) limitation... p.

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by bgmilne＠staff.telkomsa.net 02 Aug '07

02 Aug '07

On Friday 27 July 2007 17:19:26 pbrinette(a)cc.in2p3.fr wrote: > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > > about to exit beta stage. Unless the problem is related to a real > > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > > ITS will be closed. > > Currently, I've no mean to use an openldap 2.3 unless exists an RPM > update package for RHEL 4 (or CentOS). There is no update from RHEL or CentOS, but there are these (mine): http://staff.telkomsa.net/packages/rhel4/openldap/ Since you can install them in parallel, the upgrade path is quite easy ... (slapcat|slapadd2.3 after configuration). There is also: http://staff.telkomsa.net/packages/rhel3/openldap/ Regards, Buchan

1 0

(ITS#5069) SyncRepl on request
by hadmut＠danisch.de 01 Aug '07

01 Aug '07

Full_Name: Hadmut Danisch Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.180.64.215) This is an enhancement request: When having a distributed LDAP structure with a master and several SyncRepl clients, the clients can do the SyncRepl only on fixed refresh intervals (e.g. type=refreshOnly, interval=00:00:20:00) However, there are many situations where this is inappropriate, e.g. on dial-on connections, roaming notebooks, and things like that. Therefore, slapd should have a client mode where the SyncRepl process is performed only on request, but then immediately. There should be an external trigger to pull, e.g. send a signal oder do a special LDAP request. slapd should then start a SyncRepl. E.g. this could be put in scripts run at connect-time (pppd provides that kind of scripting), or when notebook autoconfiguration detects (e.g. with tools like guessnet) that it is connected to the home network to update it's local slapd. regards Hadmut

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

Quanah Gibson-Mount wrote: > --On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.92.25.194) >>> >>> >>> When using cn=config with a slapd.conf driven slapd, the value for >>> olcLogLevel is not correct: >>> >>> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >>> olcLogLevel >>> Enter LDAP Password: >>> dn: cn=config >>> olcLogLevel: None >>> >>> However: >>> >>> grep loglevel conf/slapd.conf >>> loglevel 32768 >>> >>> And the logging that is happening is actually for level 32768. >>> Modifying the loglevel works, and once that is done, the right loglevel >>> is shown. However, this makes it impossible to know what loglevel is >>> set via a remote query unless it has been changed. >> >>> From slapd.conf(5), loglevel: >> 32768 (0x8000 none) only messages that get logged >> whatever log level is set >> >> Seems to be correct. > > Yet if I modify it to be "256", then olcLogLevel is "256". If I modify > it to be "32768", then it is "32768". That's because in EMIT the loglevel goes through loglevel2bvarray(), which turns the level into an array of pretty values. You're supposed to modify the loglevel by adding multiple values, each with the descriptive name of the level you're using. The use of loglevel with OR'ed integers is stylistically deprecated. > So if the loglevel setting in > slapd.conf is "32768", then that is what it should match. In any case, > "None" has the unfortunate ring of sounding like an unset value. In LDAP, if the value were unset, the attribute would be missing, which is what you get if, for example, you set loglevel to 0. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.92.25.194) >> >> >> When using cn=config with a slapd.conf driven slapd, the value for >> olcLogLevel is not correct: >> >> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >> olcLogLevel >> Enter LDAP Password: >> dn: cn=config >> olcLogLevel: None >> >> However: >> >> grep loglevel conf/slapd.conf >> loglevel 32768 >> >> And the logging that is happening is actually for level 32768. >> Modifying the loglevel works, and once that is done, the right loglevel >> is shown. However, this makes it impossible to know what loglevel is >> set via a remote query unless it has been changed. > >> From slapd.conf(5), loglevel: > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > Seems to be correct. Yet if I modify it to be "256", then olcLogLevel is "256". If I modify it to be "32768", then it is "32768". So if the loglevel setting in slapd.conf is "32768", then that is what it should match. In any case, "None" has the unfortunate ring of sounding like an unset value. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel > is not correct: > > ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W > olcLogLevel > Enter LDAP Password: > dn: cn=config > olcLogLevel: None > > However: > > grep loglevel conf/slapd.conf > loglevel 32768 > > And the logging that is happening is actually for level 32768. Modifying the > loglevel works, and once that is done, the right loglevel is shown. However, > this makes it impossible to know what loglevel is set via a remote query unless > it has been changed. >From slapd.conf(5), loglevel: 32768 (0x8000 none) only messages that get logged whatever log level is set Seems to be correct. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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