- openldap-bugs - openldap.org

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

--On October 1, 2007 11:22:11 PM +0000 quanah(a)zimbra.com wrote: > The following files will be uploaded to the ftp site, where # will be the > assigned ITS number. URL's specifically are: <ftp://ftp.openldap.org/incoming/5161-pstak.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-dbstat.delta.out.2007-10-01> <ftp://ftp.openldap.org/incoming/5161-db_stat.out.2007-10-01> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 01 Oct '07

01 Oct '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.104.138.6) Several customers have found delta-syncrepl will lock up after a time. Today it occurred again, and this time some logging data was able to be gathered. The last operation logged was a MOD op. This matches past lockups, which were also either MOD or ADD operations. The following files will be uploaded to the ftp site, where # will be the assigned ITS number. #-dbstat.delta.out.2007-10-01 which is the db_stat information for the accesslog DB #-db_stat.out.2007-10-01 which is the db_stat information for the main DB #-pstak.out.2007-10-01 which is the pstack information for the slapd process Unfortunately no GDB info was retrieved this time, and reportedly gcore hung. The most interesting part is I see no WRITE locks held in either DB, and all the client threads are hung in a mutex.

1 0

Re: (ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by hyc＠symas.com 01 Oct '07

01 Oct '07

jclarke(a)linagora.com wrote: > I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and > behaviour is quite different, though the end result is the same. Due to multiple limitations, this is not expected to work in 2.3 at all. > On HEAD, things are quite different: > request done: ld 0x82c2228 msgid 2 > do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT > nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn > dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn > uid=root,dc=ossa,dc=linagora,dc=org > nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn > uid=replicator,dc=ossa,dc=linagora,dc=org > adresse de be_modify : 80c8840 > null_callback : error code 0x32 > syncrepl_updateCookie: rid=7 be_modify failed (50) This is Insufficient Access. You have not configured the glue databases with identical rootDN's, which is clearly documented as a requirement for glued databases. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5160) syncrepl of glued and syncrepl'd databases causes unwanted deletes on the end consumer
by jclarke＠linagora.com 01 Oct '07

01 Oct '07

Full_Name: Jonathan Clarke Version: 2.3.38 and HEAD (but with slightly different results) OS: Linux URL: ftp://ftp.openldap.org/incoming/unwanted-deletes-syncrepl-glue.tar.gz Submission from: (NULL) (213.41.243.192) Hi folks, I've come across an issue with a server using the glue overlay with one of it's subordinate databases syncrepl'd. There are two problems: 1) updating the root database's contextCSN 2) when replicating this whole server with syncrepl (to a 3rd server), certain updates cause many entries to be deleted from the consumer. The following "schema" should describe this setup more clearly (names TOP, MIDDLE and BOTTOM are for easy reference): TOP: |----------------------------| | One bdb backend: | | dc=ossa,dc=linagora,dc=org | |----------------------------| | MIDDLE: | |-------------------------------| | Two bdb backends + glue: | | 1) dc=ossa,dc=linagora,dc=org | | subordinate | | syncrepl from above server | | 2) dc=linagora,dc=org | | 'master' for this branch | | | | syncprov overlay | |-------------------------------| | BOTTOM: | |-------------------------------| | One bdb backend: | | dc=linagora,dc=org | | syncrepl from above server | |-------------------------------| All config files, and some sample data sets, are in the archive at the URL above. I have tested this on both 2.3.38 and HEAD (same version on all 3 servers), and behaviour is quite different, though the end result is the same. On 2.3.38: 1) Set up all three servers, make sure they're sync'ed. 2) Modify some attribute on the TOP server (I add a description to the root DN, dc=ossa,dc=linagora,dc=org) 3) Watch this modification propagate to the middle server. the contextCSN in dc=linagora,dc=org is not updated, but the one in dc=ossa,dc=linagora,dc=org is (equals to the entryCSN of the entry I modified). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822ec20 msgid 1 do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 007 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 007 be_search (0) syncrepl_entry: rid 007 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 007 be_modify (0) request done: ld 0x822ec20 msgid 2 do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT 8>--------------------------------------------------------------- 4) Watch the BOTTOM server (see schema above) do it's syncrepl and delete some entries below the glued database (glued on MIDDLE server, not on this one). The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- request done: ld 0x822a320 msgid 1 request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT request done: ld 0x822a320 msgid 1 do_syncrep2: rid 888 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) syncrepl_entry: rid 888 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid 888 be_search (0) syncrepl_entry: rid 888 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid 888 be_modify (0) request done: ld 0x822a320 msgid 2 do_syncrep2: rid 888 LDAP_RES_SEARCH_RESULT syncrepl_del_nonpresent: rid 888 be_delete uid=replicator,dc=ossa,dc=linagora,dc=org (0) syncrepl_del_nonpresent: rid 888 be_delete uid=root,dc=ossa,dc=linagora,dc=org (0) 8>--------------------------------------------------------------- On HEAD, things are quite different: 1) Start the TOP server. 2) Start the MIDDLE server. Errors happen immediatly, on first sync attempt. The output is the following with loglevel=stats+sync: 8>--------------------------------------------------------------- slapd starting request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f syncrepl_entry: rid=7 be_search (32) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 be_add (0) request done: ld 0x82c2228 msgid 2 do_syncrep2: rid=7 LDAP_RES_SEARCH_RESULT nonpresent_callback: rid=7 got UUID b5797e8c-0486-102c-83e0-79137da6179f, dn dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a2f834-0486-102c-83e1-79137da6179f, dn uid=root,dc=ossa,dc=linagora,dc=org nonpresent_callback: rid=7 got UUID b5a31526-0486-102c-83e2-79137da6179f, dn uid=replicator,dc=ossa,dc=linagora,dc=org adresse de be_modify : 80c8840 null_callback : error code 0x32 syncrepl_updateCookie: rid=7 be_modify failed (50) request done: ld 0x82c2228 msgid 1 syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5797e8c-0486-102c-83e0-79137da6179f dn_callback : entries have identical CSN dc=ossa,dc=linagora,dc=org ours 20071001162546.703481Z#000000#000#000000, new 20071001162546.703481Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a2f834-0486-102c-83e1-79137da6179f dn_callback : entries have identical CSN uid=root,dc=ossa,dc=linagora,dc=org ours 20071001162546.975377Z#000000#000#000000, new 20071001162546.975377Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=root,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=root,dc=ossa,dc=linagora,dc=org) syncrepl_entry: rid=7 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=7 inserted UUID b5a31526-0486-102c-83e2-79137da6179f dn_callback : entries have identical CSN uid=replicator,dc=ossa,dc=linagora,dc=org ours 20071001162546.976133Z#000000#000#000000, new 20071001162546.976133Z#000000#000#000000 syncrepl_entry: rid=7 be_search (0) syncrepl_entry: rid=7 uid=replicator,dc=ossa,dc=linagora,dc=org syncrepl_entry: rid=7 entry unchanged, ignored (uid=replicator,dc=ossa,dc=linagora,dc=org) 8>--------------------------------------------------------------- Obviously, the desired result is that entries are not deleted from the BOTTOM server when replication happens. I'm a bit at a loss as to the logic behind these updates, and how to go about correcting. I tried applying a patch backported from HEAD to 2.3.38 that makes syncrepl update the contextCSN in the real root (not the bdb database root). It works in that the contextCSN is updated correctly, but replication to BOTTOM still has unwanted deletes. The patch is in the archive attached (update-root-contextCSN.diff) and corresponds to revisions 1.308 and 1.309 in syncrepl.c CVS log. I am completely available to provide any more information necessary: logs, testing, gdb output, etc. Any help or pointers most welcome! Thanks in advance, Jon

1 0

Re: (ITS#4467) snprintf is consistenly used wrongly
by ando＠sys-net.it 29 Sep '07

29 Sep '07

h.b.furuseth(a)usit.uio.no wrote: > OpenLDAP is full of code like > ptr += snprintf( ptr, ... ); > and > bv.bv_len = snprintf( ... ); > <use bv>; Let me add that there seem to be occasional improper uses of sprintf() too (usually in marginal code, fortunately). 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 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> I just got tripped trying to import an LDIF with a cert with 16 byte >> SerialNumber. I've patched this to just use the same hexadecimal format that >> OpenSSL uses when the number is larger than ber_int_t. We really don't want >> the format to change just because someone has a BigNum library available; it >> needs to stay consistent. > > But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. > And in case somebody feeds in a very large decimal integer, we still need a > multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. OK. Does it make any sense to just move to a hex-only syntax, perfixed by "0x", with no sign as you mentioned earlier, or should we preserve compatibility with the original form, where the minus sign is allowed while a number not starting with "0x" should be treated as decimal? The latter would be probably better, but we'd need to convert decimal to hex, and this could fail if decimals are too large. 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 hyc＠symas.com 29 Sep '07

29 Sep '07

Howard Chu wrote: > I just got tripped trying to import an LDIF with a cert with 16 byte > SerialNumber. I've patched this to just use the same hexadecimal format that > OpenSSL uses when the number is larger than ber_int_t. We really don't want > the format to change just because someone has a BigNum library available; it > needs to stay consistent. But we still need to fix serialNumberAndIssuerNormalize() to normalize to Hex now. And in case somebody feeds in a very large decimal integer, we still need a multi-word decimal-to-binary converter. As such, this bug cannot be closed yet. -- -- Howard Chu Chief Architect, 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#5146) slapo-ppolicy
by ando＠sys-net.it 29 Sep '07

29 Sep '07

hyc(a)symas.com wrote: > Of course now that userPassword and authPassword already exist, all the good > attribute names are already gone. ;) "password"? 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#5159) make slap_passwd_parse() non-destructive
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc In RE23 the slap_passwd_parse() function parses the exop data destructively, so it cannot be successfully parsed again by any other function that needs to. In HEAD there is a new LBER option to specify non-destructive parsing of strings, and slap_passwd_parse() has been changed to use this option.

1 0

(ITS#5158) contrib should use separate config OID arc
by hyc＠OpenLDAP.org 29 Sep '07

29 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Currently we track config OID allocations in slapd/bconfig.c for both core modules and contrib modules. Since we really aren't maintaining the contrib modules, they should use a separate OID arc and the OIDs should be tracked elsewhere. This has been changed in HEAD, and contrib/ConfigOIDs now exists for tracking OIDs allocated to contrib modules.

1 0

(ITS#5157) dynlist shouldn't populate values unless requested
by hyc＠OpenLDAP.org 28 Sep '07

28 Sep '07

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) Submitted by: hyc Since populating the member list in a dynamic group may be a very expensive operation, the dynlist overlay should not perform this work if the member attribute wasn't requested in the search parameters. Already fixed in HEAD.

1 0

(ITS#5156) missing slapd.d man page
by gerard.ranke＠kmt.hku.nl 27 Sep '07

27 Sep '07

Full_Name: Gerard Ranke Version: 2.3.35, 2.3.38 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) Section 5.2 from the OpenLDAP Administrator's Guide mentions the slapd.d(5) man page. However, this seems to be missing from the distribution. Would it be possible to add it? Thanks for your time and effort. Best regards, Gerard Ranke

1 0

Re: (ITS#5114) pcache cache results for searches that hit size/timelimit
by rhafer＠suse.de 26 Sep '07

26 Sep '07

On Sonntag, 23. September 2007, ando(a)sys-net.it wrote: > Ralf Haferkamp wrote: > > Please note that test020 currently fails in HEAD sometime. I think this > > depends on the order in which the results for queries that hit the > > sizelimit are returned. > > I added tests for sizelimit that were consistent with my changes; > however, I'm now short of time to work on this, so feel free to back out > those test changes if you believe the code is working correctly, while > we design test improvements that are consistent with all fixes. I have rearranged the pcache test case a bit. It succeeds now on my test machine. -- Ralf

1 0

(ITS#5155) Leak in back-meta when binding as rootdn
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) back-meta leaks orb_edn after adding be_rootdn_bind() support (ITS#4962) p.

1 0

Re: (ITS#5121) IDL cache issue
by ando＠sys-net.it 26 Sep '07

26 Sep '07

Howard Chu wrote: > ando(a)sys-net.it wrote: >> To reproduce: >> >> - set idlcache >> >> - search one entry, so that the idl gets cached >> >> - delete that entry, so that the idl gets cleared - but head/tail don't >> >> - search another entry so that it gets cached - head/tail are corrupted >> >> I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure >> about re23). > > Coverity shows this patch has introduced a NULL pointer dereference. > @@ -364,6 +381,9 @@ > ee = bdb->bi_idl_lru_tail; > for ( i = 0; i < 10; i++, ee = eprev ) { > eprev = ee->idl_lru_prev; > + if ( eprev == ee ) { > + eprev = NULL; > + } > if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { > ee->idl_flags ^= CACHE_ENTRY_REFERENCED; > continue; > > What's the purpose of this change Make sure bi_idl_lru_tail gets set to NULL if purging the cache makes it empty. Perhaps it's an overshoot. > and should you be testing for a NULL > now in the for loop conditions? Yes, I realize I should test for ee != NULL in the for loop. 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#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Pierangelo Masarati [mailto:ando@sys-net.it] > Sent: Wednesday, September 26, 2007 2:54 PM > To: mhardin(a)symas.com > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5154) Sequential binds to back-meta cause assertion > failiure > > mhardin(a)symas.com wrote: > > Full_Name: Matthew Hardin > > Version: 2.3.38 > > OS: N/A > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (12.168.121.2) > > > > > > Multiple binds on the same connection where at least one bind ends up > being [...] > > /* FIXME: in some cases (e.g. unavailable) > > * do not assume it's not candidate; rather > > * mark this as an error to be eventually > > I think the "real" fix should be different: binds should always receive > a fresh connection from meta_back_getconn(), which shouldn't be put > into the cache at all. meta_back_bind() should cache them only in case > of success, otherwise they should be destroyed. This would allow to > remove the need to set a BINDING flag to guarantee connections used for > bind are not shared. I agree that would be a better fix. > In the meanwhile, the solution you propose should be just fine, as it > fills the hole occurring when a bind fails. > > I'll work at that ASAP. Thanks! -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5121) IDL cache issue
by hyc＠symas.com 26 Sep '07

26 Sep '07

ando(a)sys-net.it wrote: > To reproduce: > > - set idlcache > > - search one entry, so that the idl gets cached > > - delete that entry, so that the idl gets cleared - but head/tail don't > > - search another entry so that it gets cached - head/tail are corrupted > > I've a fix for this about to come (affects 2.4.5 as well, sigh; not sure > about re23). Coverity shows this patch has introduced a NULL pointer dereference. @@ -364,6 +381,9 @@ ee = bdb->bi_idl_lru_tail; for ( i = 0; i < 10; i++, ee = eprev ) { eprev = ee->idl_lru_prev; + if ( eprev == ee ) { + eprev = NULL; + } if ( ee->idl_flags & CACHE_ENTRY_REFERENCED ) { ee->idl_flags ^= CACHE_ENTRY_REFERENCED; continue; What's the purpose of this change, and should you be testing for a NULL now in the for loop conditions? -- -- Howard Chu Chief Architect, 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#5154) Sequential binds to back-meta cause assertion failiure
by ando＠sys-net.it 26 Sep '07

26 Sep '07

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.168.121.2) > > > Multiple binds on the same connection where at least one bind ends up being > passed through to a target and where the credentials for that bind are incorrect > will cause back-meta to throw an assertion failure during a subsequent bind. In > this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: > Assertion `tmpmc == mc' failed". > > Analysis: > In bind.c there is no cleanup of the metaconn structure after a failed bind to a > target database. This is ordinarily not a problem, as most applications perform > an unbind immediately after a failed bind and so fail to trigger this bug. > However, applications such as pam_ldap will perform several binds to as many as > two different identities on the same connection, and the credentials for one of > those identities are routinely incorrect. This bug causes the metaconn structure > from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then > found during the re-insertion of a metaconn structure from a subsequent bind > (approx between lines 209-258 in bind.c), causing the assertion failure and > killing slapd in the process. > > Note: This bug can be exploited as a DOS attack, as the behavior is relatively > easy to reproduce on an unpatched system with a short perl script. > > > Proposed Fix: > The simplest and best fix appears to be to mark the metaconn struct from the > failed bind as tainted. This causes the struct to be deleted in the call to > meta_back_release_conn around line 281. > > The patch is as follows: > > bind.c > *************** > *** 189,194 **** > --- 189,198 ---- > > if ( lerr != LDAP_SUCCESS ) { > rc = rs->sr_err = lerr; > + /* Mark the meta_conn struct as tainted so > + * it'll be freed by meta_conn_back_destroy below */ > + LDAP_BACK_CONN_TAINTED_SET( mc ); > + > /* FIXME: in some cases (e.g. unavailable) > * do not assume it's not candidate; rather > * mark this as an error to be eventually I think the "real" fix should be different: binds should always receive a fresh connection from meta_back_getconn(), which shouldn't be put into the cache at all. meta_back_bind() should cache them only in case of success, otherwise they should be destroyed. This would allow to remove the need to set a BINDING flag to guarantee connections used for bind are not shared. In the meanwhile, the solution you propose should be just fine, as it fills the hole occurring when a bind fails. I'll work at that ASAP. 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#5154) Sequential binds to back-meta cause assertion failiure
by mhardin＠symas.com 26 Sep '07

26 Sep '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.168.121.2) Multiple binds on the same connection where at least one bind ends up being passed through to a target and where the credentials for that bind are incorrect will cause back-meta to throw an assertion failure during a subsequent bind. In this situation back-meta prints the message "slapd: bind.c:229: meta_back_bind: Assertion `tmpmc == mc' failed". Analysis: In bind.c there is no cleanup of the metaconn structure after a failed bind to a target database. This is ordinarily not a problem, as most applications perform an unbind immediately after a failed bind and so fail to trigger this bug. However, applications such as pam_ldap will perform several binds to as many as two different identities on the same connection, and the credentials for one of those identities are routinely incorrect. This bug causes the metaconn structure from the failed bind to be left in the mi_conninfo.lai_tree avl tree and then found during the re-insertion of a metaconn structure from a subsequent bind (approx between lines 209-258 in bind.c), causing the assertion failure and killing slapd in the process. Note: This bug can be exploited as a DOS attack, as the behavior is relatively easy to reproduce on an unpatched system with a short perl script. Proposed Fix: The simplest and best fix appears to be to mark the metaconn struct from the failed bind as tainted. This causes the struct to be deleted in the call to meta_back_release_conn around line 281. The patch is as follows: bind.c *************** *** 189,194 **** --- 189,198 ---- if ( lerr != LDAP_SUCCESS ) { rc = rs->sr_err = lerr; + /* Mark the meta_conn struct as tainted so + * it'll be freed by meta_conn_back_destroy below */ + LDAP_BACK_CONN_TAINTED_SET( mc ); + /* FIXME: in some cases (e.g. unavailable) * do not assume it's not candidate; rather * mark this as an error to be eventually

1 0

(ITS#5153) Performance of large multi-valued attributes
by hyc＠OpenLDAP.org 24 Sep '07

24 Sep '07

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc A bit late, but this is just for tracking purposes. HEAD now supports a "sortvals" directive for declaring that specific attributes' values be maintained in sorted order. This allows Compare/Filter operations on attributes with very many values to be completed more efficiently. (From O(n) to O(logn).) Modify operations are also similarly improved.

1 0

Re: (ITS#5152) too much logging
by hyc＠symas.com 24 Sep '07

24 Sep '07

babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3.32 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > We are having hell of problems in production with # logs getting > generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb > files). > > No debugging/logging turned in slapd. > > Log rotate scripts is moving the logs to diff location to keep the prod up..but > few times we ran of space and I don't find any clue on minimize and log only for > updated transactions. It seems BDB is recording every read/write(not sure)..I > can't enable Auto_Achieve as need them for recovery. > > Any known issue in the space? How to turn of unwanted logging of BDB? Learn how to use BerkeleyDB. http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/… The ITS is for reporting actual bugs in the software. There is no bug here. This ITS will be closed. -- -- Howard Chu Chief Architect, 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#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by quanah＠zimbra.com 24 Sep '07

24 Sep '07

--On Monday, September 24, 2007 3:23 PM +0000 tan7f(a)virginia.edu wrote: > > --Apple-Mail-1--260703270 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > Hello OpenLdap Developers, > > I haven't heard anything about the two bugs I've submitted in the > jldap libraries, so I'd like to explain why I feel that these two > issues are important to have fixed. Note that the work on JLDAP is generally done a very different set of developers than most of the OpenLDAP folks, so how soon they'll be addressed I don't know. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#5152) too much logging
by Babu.Suresh＠pacificlife.com 24 Sep '07

24 Sep '07

Guys, Any input is greatly appreciated. Please let me know if you need more details of the issue. Thank you _babu -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: Monday, September 24, 2007 3:30 PM To: Suresh, Babu Subject: Re: (ITS#5152) too much logging *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5152. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5152) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5152) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=5152 Please remember to retain your issue tracking number (ITS#5152) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

(ITS#5152) too much logging
by babu.suresh＠pacificlife.com 24 Sep '07

24 Sep '07

Full_Name: Babu Version: 2.3.32 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.11.27) Hello, We are having hell of problems in production with # logs getting generated..almost 4Gig worth of transaction binary/BDB logs in a day(4000 10mb files). No debugging/logging turned in slapd. Log rotate scripts is moving the logs to diff location to keep the prod up..but few times we ran of space and I don't find any clue on minimize and log only for updated transactions. It seems BDB is recording every read/write(not sure)..I can't enable Auto_Achieve as need them for recovery. Any known issue in the space? How to turn of unwanted logging of BDB? ==================Here are the detail of prod volume & DB_CONFIG file===== openldap-2.3.32&BDB 4.5.20 our ldap/BDB is generating too many logs file. Total records in ldap/BDB - 110k Reads - 10k/day Updates - 1k/day =================DB_CONFIG======= # one 0.25 GB cache #set_cachesize 0 268435456 1 set_cachesize 0 5242880 1 # Data Directory set_lk_max_locks 8000 set_lk_max_lockers 8000 set_lk_max_objects 8000 set_lg_max 8048576 ===============SLAPD.conf======== Nothing special in and inxed we have are======== #index index uid eq index cn eq index uniqueMember eq index objectClass pres,eq ============= thank you # Transaction Log settings set_lg_regionmax 262144 set_lg_bsize 2097152

1 0

Re: (ITS#5142) and (ITS#5143) Why I think these bugs are important to have fixed.
by tan7f＠virginia.edu 24 Sep '07

24 Sep '07

--Apple-Mail-1--260703270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello OpenLdap Developers, I haven't heard anything about the two bugs I've submitted in the jldap libraries, so I'd like to explain why I feel that these two issues are important to have fixed. I'd like to create a new LdapConnection with a custom LdapSocketFactory and I want a timeout value set on the socket so that the connect method will timeout in case there is no route to the host or some other networking issue. The documentation leads me to believe that I can do the following. LdapConnection.setSocketFactory(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc = new LdapConnection(timeout); lc.connect ("127.0.0.1", 636); This won't work because the LdapConnection(int) constructor disregards the LdapSocketFactory that is set with the setSocketFactory method and instead uses the default non-SSL encrypted socket. Ok, lets try a workaround. lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.setTimeout(timeout); // <--- causes a nullPointerException lc.connect("127.0.0.1", 636); // Program never even gets here. Ok, this is even worse. I now get a nullPointerException in the jldap library itself. Again, nothing in the documentation says to avoid setting the timeout until after you call connect() lc = new LdapConnection(new LDAPJSSESecureSocketFactory()); int timeout = 5000; // 5 second timeout lc.connect("127.0.0.1", 636); lc.setTimeout(timeout); Well, that works, but I'm not setting the timeout until after the connect which isn't what I need. What follows is the only way I can think of getting it to work. class TimeoutLdapSocketFactory extends LDAPJSSESecureSocketFactory { m_timeout = 0; TimeoutLdapSocketFactory() { super (); } TimeoutLdapSocketFactory(int timeout) { this(); m_timeout = timeout; } Socket createSocket (host, port) { Socket socket = super.createSocket(host,port); if (timeout > 0) socket.setSoTimeout(m_timeout); return socket; } lc = new LdapConnection(new TimeoutLdapSocket(timeout)); lc.connect("127.0.0.1", 636); That's a lot of code to do what is already there in the LdapConnection class. If either of the two bugs I've submitted is fixed, then the above use case would be easy to do with-out the uglyness above. I believe #5142 to be a serious bug indeed since it can lead to a nullPointerException in the library. Thank you, Tim Nowaczyk -- Timothy Nowaczyk Network Systems Engineer University of Virginia - ITC tan7f(a)virginia.edu --Apple-Mail-1--260703270 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPujCCBIIw ggNqoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJn aW5pYTEYMBYGA1UEBxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZp cmdpbmlhMRswGQYDVQQDExJVVkEgVVNIRVIgUEtQIENBIDExJTAjBgkqhkiG9w0BCQEWFnBraW1h c3RlckB2aXJnaW5pYS5lZHUwHhcNMDcwNzEyMjEyNzE0WhcNMjYwMjI1MDAwMDAwWjCBrzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExJTAjBgkqhkiG9w0BCQEWFnBraW1hc3RlckB2 aXJnaW5pYS5lZHUxKzApBgNVBAMTIlVWQSBTdGFuZGFyZCBBc3N1cmFuY2UgVVNIRVIgU0tQIDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbO90WPYQnSOSvhwkIlhh3fLVaHi6X2v2+ kJ7njhzZg8zYoTwMa/sag84dgGu9CCmkzvYryD23mwdQ5oZX58ZyrYCETkcuV5Aycbi70ekTrQPP 1b4x4/sK3PDFSn2S2RB1sNlYy15DI6sIO5mVrV16ML+DGBSJbwGoJRjd+2L5MxkhPJraw5+k2us7 ABxvRpFgaA4TXwJiM8/idtsTNMv2XTR6zUJ9FPq8uOMLtiupbWe2K2tXDDeBSzBu7Z7RzNzxSsZz 72PjtEHhuNQ4I1hsKx/HT2gdxrCb6KxSyGo+QbYxwj5znRkIAFNEQPh6U6EPeDuzJbY/VuFfpsil 3tPZAgMBAAGjgbYwgbMwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFAGp d8MuTIwww/Lbfd5nlCrBvuQZMB8GA1UdIwQYMBaAFDdB3axEwhAHmpxMkx2UHyiXRyUxMFMGA1Ud IARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6Ly93d3cucGtpLnZpcmdpbmlh LmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEAfEvJKxRHr9gy0MufEFva x+QQs2dUN8oocl8jxWsQrQt5Hc6Azzfn2Zp3es10iYkCGNOqj+cRtwoljuWv2yVWm869+xgxskjn uHPnaat84VzXN85i8ILbBZkVYPk1bO2SHjL97RrGvUqi2bJf8cSlzO7g+yTX9/yX0r0QKL4UNHdI p3l3OeTZ0PBLKNhlr1wb6LRpl5+lRZQPWeCij/4e3wA7v9OmWXvevT9YprYTwEmCypPUbnjFeMnP F+hwSgCC+Yov12kP3M+kDwXWpidFGk5p6nQ5c/cGGPd+x8Ek4VjjCw+7TfumwxEJSIX0NmjM+lDx ykVtAMDS11nQ65/VEjCCBVwwggREoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjEwHhcNMDcwNzExMjIyOTQ3WhcNMjYwMjI2MTgwMDAwWjCBnzELMAkG A1UEBhMCVVMxETAPBgNVBAgTCFZpcmdpbmlhMRgwFgYDVQQHEw9DaGFybG90dGVzdmlsbGUxHzAd BgNVBAoTFlVuaXZlcnNpdHkgb2YgVmlyZ2luaWExGzAZBgNVBAMTElVWQSBVU0hFUiBQS1AgQ0Eg MTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdpbmlhLmVkdTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANnbscQ3ClhftaALCDqjnqvzU1MVfDmnSNFjSBcGyRRKxNEduA/O4/iD CQ3lKJkRdjhIXN5e5UTe6LsmMY14uPBJOVINmFPiGfsi22LxslYiaGMStWIj3lNF+ZawyUX53WDD IrjlYaBn3wi/m0tkWPLzsgeiRIovL0KVG4XRlkJ70upNCIv6GHP4W6rsa2hqC/gU1QdL+V2XJzE7 sT7l6CysRr01FiyRTOxdoSz+jJFmTTt892sWVry8B7nocD/ltffQ1pQJta4Ve/xWT+TvRPF3X7jn ggOPIYbq0mYRAhWduV1BzlBA8bkTc8AHf8ukjRGydCAPc4OXMamhJ4uETCECAwEAAaOCAeowggHm MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ3Qd2sRMIQB5qcTJMd lB8ol0clMTB9BgNVHSMEdjB0gBQmnSLq7LAPayEK9tkvIMplUOwb06FZpFcwVTELMAkGA1UEBhMC VVMxITAfBgNVBAoTGFVTIEhpZ2hlciBFZHVjYXRpb24gUm9vdDEMMAoGA1UECxMDQ0ExMRUwEwYD VQQDEwxVU0hFUiBDQTEgdjGCAQQweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzAChidodHRwOi8v aDEudXNoZXJjYS5vcmcvYWlhL2NhMS1jZXJ0cy5wN2IwMwYIKwYBBQUHMAKGJ2h0dHA6Ly9oMi51 c2hlcmNhLm9yZy9haWEvY2ExLWNlcnRzLnA3YjBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vaDEu dXNoZXJjYS5vcmcvY3JsL2NhMS5jcmwwJ6AloCOGIWh0dHA6Ly9oMi51c2hlcmNhLm9yZy9jcmwv Y2ExLmNybDBOBgNVHSAERzBFMEMGBFUdIAAwOzA5BggrBgEFBQcCARYtaHR0cHM6Ly93d3cudXNo ZXJjYS5vcmcvcHJhY3RpY2VzL2NhMS9jcHMucGRmMA0GCSqGSIb3DQEBBQUAA4IBAQCHbtcZxR5o 9B0MgMds0g3g9DBLZSJEi6kRY6heNocsmSsRxEsqE37R6gVtRg3xfTcjJG9E4J4fClB8EK5EDPRo UAJZExJE47aHNXT7KtHgYKqU5dQUXlGi/ZyPpJOA5Nm8xQ+wiDw3kg8AAnM1WrPNnTUiTCYEUqBI KY8AABaJ9CwVHsnu0wV04z4DtbiZgEhxBOczp8L+AveIsJhCTRc3VNlDmHPu9bh4VoyMnbzwlYKk ItLkehDC5xE2ZPTMfC0VYtL+LEDlbGfR0YpzbTzxP3X3dxsmFbIyXAfNvj5gTqViDcgN9CTzblDv oseZLtO0Te+e/YFeTRUBe/CcmUlmMIIF0DCCBLigAwIBAgIDAgQUMA0GCSqGSIb3DQEBBQUAMIGv MQswCQYDVQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxs ZTEfMB0GA1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFz dGVyQHZpcmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBT S1AgMTAeFw0wNzA4MDgxMzAzMDBaFw0wODA4MDgxMzAzMDBaMIGVMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTEeMBwGA1UECxMVVVZBIFN0YW5kYXJkIFBLSSBV c2VyMSEwHwYJKoZIhvcNAQkBFhJ0YW43ZkB2aXJnaW5pYS5lZHUxIjAgBgNVBAMTGVRpbW90aHkg QWxsZW4gTm93YWN6eWsgMTMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKEo43l7/lWiNKOe vtraIMIje77qJCSifhZ0CtrBT15E8HPQajBcFnqJ3U//6vvrEeN79de3Gvwygia0SwkgzjtFEsh8 /fLHKvYUDDlhyJxgbaVw3Ay1Ii9cHTyA8hopglAhyVweu08hwrnmSUDBsV+ugqV3AANQ0QwkXPDs WbIbAgMBAAGjggKPMIICizALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBSt9bmjP/g2cbvyzw+7IfnWfnDliDAJBgNVHRMEAjAAMB8GA1UdIwQYMBaA FAGpd8MuTIwww/Lbfd5nlCrBvuQZMEEGA1UdEQQ6MDigIgYKKwYBBAGCNxQCA6AUDBJ0YW43ZkBW aXJnaW5pYS5FRFWBEnRhbjdmQFZpcmdpbmlhLkVEVTCCAXgGA1UdHwSCAW8wggFrMH2ge6B5hnds ZGFwOi8vd3d3LnBraS52aXJnaW5pYS5lZHUvYz1VUyxvPVVuaXZlcnNpdHklMjBvZiUyMFZpcmdp bmlhLG91PVVWQSUyMFN0YW5kYXJkJTIwQXNzdXJhbmNlJTIwVVNIRVIlMjBTS1AlMjAxLGNuPTAy MDQxNDB9oHugeYZ3bGRhcDovL3d3dy5wa2kudmlyZ2luaWEuZWR1L2NuPTAyMDQxNCxvdT1VVkEl MjBTdGFuZGFyZCUyMEFzc3VyYW5jZSUyMFVTSEVSJTIwU0tQJTIwMSxvPVVuaXZlcnNpdHklMjBv ZiUyMFZpcmdpbmlhLGM9VVMwa6BpoGeGZWh0dHA6Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9jZ2kt YmluL2dldC1jcmw/b3U9VVZBJTIwU3RhbmRhcmQlMjBBc3N1cmFuY2UlMjBVU0hFUiUyMFNLUCUy MDEmY249MDIwNDE0MFMGA1UdIARMMEowSAYJKwYBBAG0dgEBMDswOQYIKwYBBQUHAgEWLWh0dHA6 Ly93d3cucGtpLnZpcmdpbmlhLmVkdS9zdGFuZGFyZC9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOC AQEAY0SUBCrlT0E9VPUQy3lTVDYNQ+ewR3dPa+D4U+gqThk3mbOWSXWEOsYTw9BYOljv4UClAY5M Uhp1Iyj7twzIG8lJnZhVP3G/ToU+8fkCCPUdAH+MJ6eshdZaeEEA/a2RzB0XvvmAfYK5x3e2yYLM tOvfBHrRAl6m5O7wU2t6iykU6vGdL+MB9iqlylY2bxQ0x0NaW5KPL0XuPLgwxVvcds7eIDGOoy7+ WMDaY0miUqsq4PKjg98dnY5BaSUwGFyxhFocw8xtTVdls5VKh3jEvhYyq9ejTHFv49dEnXdmSZ1Y Z3p98sEfQ12+CtFUbzlwphhJELXdC4nm71zFPcXg8zGCA1cwggNTAgEBMIG3MIGvMQswCQYDVQQG EwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0GA1UE ChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZpcmdp bmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQIDAgQU MAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDkyNDE1MjI1OFowIwYJKoZIhvcNAQkEMRYEFD9bKXbPWwwDKjUSyibAUFSKfHnjMIHIBgkr BgEEAYI3EAQxgbowgbcwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhWaXJnaW5pYTEYMBYGA1UE BxMPQ2hhcmxvdHRlc3ZpbGxlMR8wHQYDVQQKExZVbml2ZXJzaXR5IG9mIFZpcmdpbmlhMSUwIwYJ KoZIhvcNAQkBFhZwa2ltYXN0ZXJAdmlyZ2luaWEuZWR1MSswKQYDVQQDEyJVVkEgU3RhbmRhcmQg QXNzdXJhbmNlIFVTSEVSIFNLUCAxAgMCBBQwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYD VQQGEwJVUzERMA8GA1UECBMIVmlyZ2luaWExGDAWBgNVBAcTD0NoYXJsb3R0ZXN2aWxsZTEfMB0G A1UEChMWVW5pdmVyc2l0eSBvZiBWaXJnaW5pYTElMCMGCSqGSIb3DQEJARYWcGtpbWFzdGVyQHZp cmdpbmlhLmVkdTErMCkGA1UEAxMiVVZBIFN0YW5kYXJkIEFzc3VyYW5jZSBVU0hFUiBTS1AgMQID AgQUMA0GCSqGSIb3DQEBAQUABIGAKppmxD98ZrUSeu76i+2qXl3WV18+NCFKNFF//HeUl4aTKtEq x7K/BLdtJWyU8P+5SqoLRWG/86hBb2ERZNDozP5/6BC/0Gwuh9TUfVyRgxldQL9z8RNoMfv5T9g4 RlrQB9LGxVyAz3t7w3go8xkTBuRR2zLEn183lLBLY6CCpB8AAAAAAAA= --Apple-Mail-1--260703270--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs