openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

Re: (ITS#7221) Support private keys in PKCS #8 in slapd when linked with gnutls
by hyc＠symas.com 07 Apr '12

07 Apr '12

komyagin(a)altell.ru wrote: > Full_Name: Alexander Komyagin > Version: 2.4.23 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.16.156.18) > > > Hi! I found out that when slapd is linked with gnutls, it fails to parse private > key on startup if the one is given in PKCS #8 form (TLS init def ctx failed: > -207). > > The problem is in tlsg_ctx_init() (tls_g.c) function, which calls > gnutls_x509_privkey_import() from gnutls. But gnutls_x509_privkey_import() is > designed to support only RSA/DSA keys, while for PKCS#8 > gnutls_x509_privkey_import_pkcs8() shall be used. > > I think that incorporating such enhancement for slapd would make it even better > (for example, some popular commands like "openssl req" generate keys in PKCS #8) > :) Especially when such enhancement can be done in a few lines of code (just > like certtool does): Please read http://www.openldap.org/devel/contributing.html and submit an actual patch if you want this suggestion to be considered. > if (!info.pkcs8) > ret = gnutls_x509_privkey_import (key,&pem, info.incert_format); > > /* If we failed to import the certificate previously try PKCS #8 */ > if (info.pkcs8 || ret == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) > { > /* first try to import the key without asking any password */ > ret = gnutls_x509_privkey_import_pkcs8 (key,&pem, > info.incert_format, > NULL, GNUTLS_PKCS_PLAIN); > if (ret< 0) > { > if (info.pass) > pass = info.pass; > else > pass = get_pass (); > ret = gnutls_x509_privkey_import_pkcs8 (key,&pem, > info.incert_format, > pass, 0); > } > } > > -- -- 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#7202) slapo-memeberof crashing OL 2.4.30
by hyc＠symas.com 07 Apr '12

07 Apr '12

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: 2.4.30 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.174.164.11) > > > Hi, I'm facing crashes with openldap 2.4.30 (actually the RE24 of the day before > the release, but nothing changed in the meantime). > > I have a consumer starting from scratch with an empty db. During his starting he > populates his db by connecting to 4 servers which are part of a 4-way > multi-master cluster. They are running a previous version of OpenLDAP. > We are doing an upgrade of our deployment just to solve an issue we face from > time to time consisting in data corruption. > This bug, which is not the target of this ITS, is able to trigger a crash of the > slave slapd 2.4.30. > > During the first synchronization the consumer is receiving the entire db and I > can see on this slave, in the logs, coming two odd entries, like this one: Please send the complete consumer config. Also the provider config and sample DB. > Please let me know if you keed other details. > Thanks > Marco -- -- 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#7110) cn=config mixes values
by hyc＠symas.com 07 Apr '12

07 Apr '12

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.26 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.232.151) > > > Hi, > > I try to modify valuse of eg. olcAccess with a certain order, I get different > values if numbered values are in the correct order or not. > > Case 1 (normal): > > dn: olcDatabase={3}bdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write > > Result: > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write Cannot confirm. I get 0, 1, and 2 in the expected order. > Case 2 (inversed values): > > dn: olcDatabase={3}bdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > > Result: > olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write > olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write > olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write > > The two last values are incorrectly mixed. Wrong, this works as designed. See draft-chu-ldap-xordered-xx section 3.3. Closing this ITS. -- -- 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#7224) Core dump while trying to run slapd
by hyc＠symas.com 07 Apr '12

07 Apr '12

ashish gawarikar wrote: > On 4/6/2012 10:22 AM, Howard Chu wrote: >> >> Find out why oc->oc_names is NULL. It should not be. Seems like you >> have an invalid schema definition. >> > I have fixed the objectClasses that were violating by adding > "extensibleObject". > > Also, the slapadd-ing should not "core", and give the right error message. Agreed. But since you haven't provided us with the steps to reproduce the error, we have nothing to go on. -- -- 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#7236) new test030-relay failure in old code
by hyc＠symas.com 07 Apr '12

07 Apr '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.10->latest RE24 > OS: Linux x86_64 > URL: http://folk.uio.no/hbf/testrun.test030.ldif.tgz > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > ./run -b<bdb/hdb/mdb/ldif> test030-relay > all fail in openldap-2.4.10 and current RE24 (I did not test earlier). > > It always fails on my laptop, but succeeds on my older workstation. > Both have > Red Hat Enterprise Linux Workstation release 6.2 (Santiago) > gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) > Also it succeeds on a host with RHEL 5.8; gcc 4.1.2. > > OpenLDAP confiruation: > ./configure (--disable-backends) --enable-relay --enable-ldap --enable-rwm > > Output, slapcat output and testrun directory enclosed. Seems to have something to do with IPv6 support and whether there's a listener on ::1 port 9012. Here's your slapd.1.log at the point of divergence: ldap_chase_v3referral: msgid 3, url "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9012 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying ::1 9012 ldap_pvt_connect: fd: 16 tm: -1 async: 0 anonymous rebind via ldap_sasl_bind("") ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 14 bytes to sd 16 ldap_result ld 0x7fd9a0002120 msgid 5 wait4msg ld 0x7fd9a0002120 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x7fd9a0002120 msgid 5 all 1 ** ld 0x7fd9a0002120 Connections: * host: localhost port: 9012 refcnt: 2 status: Connected last used: Fri Apr 6 22:32:52 2012 rebind in progress queue is empty Here's mine, from a successful run: ldap_chase_v3referral: msgid 3, url "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" ldap_send_server_request ldap_new_connection 0 1 1 ldap_int_open_connection ldap_connect_to_host: TCP localhost:9012 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying 127.0.0.1:9012 ldap_pvt_connect: fd: 16 tm: -1 async: 0 ldap_close_socket: 16 ldap_err2string Unable to chase referral "ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub" (-1: Can't contact LDAP server) ber_scanf fmt ({v) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_url_parse_ext(ldap://localhost:9012/ou=Referrals,o=Beispiel,c=DE??sub) 4f805943 ==> rewrite_context_apply [depth=1] string='ou=Referrals,o=Beispiel,c=DE' 4f805943 ==> rewrite_context_apply [depth=1] res={0,'NULL'} 4f805943 [rw] referralDN: "ou=Referrals,o=Beispiel,c=DE" -> "ou=Referrals,o=Beispiel,c=DE" 4f805943 => send_search_reference: dn="(null)" ber_flush2: 64 bytes to sd 9 4f805943 <= send_search_reference I believe your test environment is corrupted; you had a server listening on 9012 when no such server should have been present. -- -- 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#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

I wrote: > Aha, slapd_daemon() sets i=0 after starting the threads. > Reproduced the crash now by sleeping before setting i=0. Reproduced in unpatched RE24, I mean. It's fixed in master. Hallvard

1 0

Re: (ITS#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 12:38:30 GMT, h.b.furuseth(a)usit.uio.no wrote: > Fixed in master, e6a25b2db6d7f4dc5d3370e06e3a3e03c5a6635d. > > Or at least, fixed some broken code in master. But I wonder > why it usually worked before. Testing with sleep(1) before > reading tid = *(int*)ptr in slapd_daemon_task() ought > to fail (lets caller increment i first), but doesn't. Aha, slapd_daemon() sets i=0 after starting the threads. Reproduced the crash now by sleeping before setting i=0. This ITS probably explains a bunch of other problems, in that all 'slapd_daemon_task's usually have been running with tid=0, even if there were more listeners. assert(tid==0) in slapd_daemon_task does not crash when starting slapd with multiple URLs, unless I sleep after the loop which starts the threads. -- Hallvard

1 0

Re: (ITS#7231) back0hdb search results disappear depending on search base
by hyc＠symas.com 07 Apr '12

07 Apr '12

hume-ol(a)bofh.ca wrote: > Full_Name: Brandon Hume > Version: -OPENLDAP_REL_ENG_2_4-0e03b13 > OS: Redhat AS6 > URL: http://den.bofh.ca/~hume/ldap_missing_results.tar.gz > Submission from: (NULL) (2610:170:2c00:7:224:1ff:fed4:b4ff) Thanks for the report and test case. Fixed now in git master. > Firstly, using RE24 built with the following ./configure: > > > #!/bin/sh > env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib > -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ > ./configure --prefix=/appl/ldap \ > --libexecdir=/appl/ldap/sbin --localstatedir=/var/run > --datadir=/appl/ldap/data \ > --sysconfdir=/appl/ldap/etc --mandir=/appl/ldap/man > --with-subdir=no \ > --disable-rlookups --with-tls=openssl \ > --enable-slapd --enable-crypt --with-cyrus-sasl=no > --enable-debug \ > --enable-dynamic --enable-modules \ > --enable-backends=mod --enable-overlays=mod --enable-sql=no \ > --enable-perl=no --enable-ndb=no --enable-shell=no > > Paired with BerkeleyDB built with the following: > > #!/bin/sh > env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib > -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ > ../dist/configure --prefix=/appl/ldap > > DIT has 131207 entries. Search results will come and go as you shorten the > search base. For example, when searching for "maillocaladdress=vbroken(a)dal.ca", > which has the full DN of > "cn=broken129251,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA", the following > will occur: > > Searching with base=cn=dal,cn=Mailmaps,cn=services,dc=dal,dc=ca: Found. > Searching with base=cn=Mailmaps,cn=services,dc=dal,dc=ca: NOT found. > Searching with base=cn=services,dc=dal,dc=ca: NOT found. > Searching with base=dc=dal,dc=ca: Found. > > cn=dal has 123312 children, which is very high. However, breaking the branch up > into subcontainers, none of which had more than 10k entries, did not cure the > problem. > > With olcLogLevel=any, the following is notable: > > Successful search: > > > Apr 5 21:09:01 kil-ds-3 slapd[17628]: => > hdb_dn2idl("cn=dal,cn=mailmaps,cn=services,dc=dal,dc=ca") > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011AND > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011OR > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_index_read: failed (-30988) > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=0, > first=0, last=0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=0 > last=0 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates > (mailLocalAddress) > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_index_read 1 candidates > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=1, > first=129301, last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_search_candidates: id=1 first=129301 > last=129301 > Apr 5 21:09:03 kil-ds-3 slapd[17628]: entry_decode: "" > Apr 5 21:09:03 kil-ds-3 slapd[17628]:<= entry_decode() > Apr 5 21:09:03 kil-ds-3 slapd[17628]: => test_filter > > Unsuccessful search: > > > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => > hdb_dn2idl("cn=mailmaps,cn=services,dc=dal,dc=ca") > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011AND > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011OR > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_index_read: failed (-30988) > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=0, > first=0, last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=0 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates > (mailLocalAddress) > Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_index_read 1 candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_equality_candidates: id=1, > first=129301, last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=1 first=129301 > last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=1 > first=129301 last=129301 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_list_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]:<= bdb_filter_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_search_candidates: id=0 first=3 > last=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: hdb_search: no candidates > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: conn=1001 op=1 p=3 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: err=0 matched="" > text="" > Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_response: msgid=2 tag=101 > err=0 > Apr 5 21:10:34 kil-ds-3 slapd[17628]: conn=1001 op=1 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > I'm including a link to a tarball that contains: > - My (simplified) config, that still produces the problem. I'm managed to > remove locally-created schemas. > - My test LDIF, containing the entries that can produce the problem. > They've been anonymized, but it doesn't affect the problem. A server loaded > with the above config and this DIT will be consistently unable to find the > "maillocaladdress=vbroken(a)dal.ca" entry at cn=services,dc=dal,dc=ca search > base. > - My test script, test_ldap.sh, that searches for the above entry at the > levels in between it and the base naming context (dc=dal,dc=ca). > > I can provide more if needed, up to and including the compiled binaries. > > -- -- 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#7233) SLAP_SOCK_NOT_ACTIVE() crash during shutdown
by h.b.furuseth＠usit.uio.no 07 Apr '12

07 Apr '12

On Sat, 7 Apr 2012 05:52:15 GMT, h.b.furuseth(a)usit.uio.no wrote: > test058(hdb): SLAP_SOCK_NOT_ACTIVE() crashed during shutdown > because slap_daemon[id].sd_index is NULL: Fixed in master, e6a25b2db6d7f4dc5d3370e06e3a3e03c5a6635d. Or at least, fixed some broken code in master. But I wonder why it usually worked before. Testing with sleep(1) before reading tid = *(int*)ptr in slapd_daemon_task() ought to fail (lets caller increment i first), but doesn't. -- Hallvard

1 0

Re: (ITS#7232) Searching for Deleted Objects
by michael＠stroeder.com 07 Apr '12

07 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030803070108020903050607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable rai.abhishek(a)yahoo.com wrote: > i am try to developed a small c# application through which i want to ge= t all > deleted objects information from OpenLDAP.i am using SQL db as a back-e= nd at the > time of set up the OpenLDAP server.i am enable to search deleted entity= > information (person,group etc) from openldap.as per my finding i am ena= ble to > find any procedure or trigger in OpenLDAP database. so please suggest m= e how can > i get this information from OpenLDAP. Such a question should be posted to the openldap-technical mailing list n= ot to this bug tracker. Ciao, Michael. --------------ms030803070108020903050607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNzExMjEzMlowIwYJKoZIhvcNAQkEMRYE FJpFJ3gQjj84ntWcodllfXVA507OMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAN+l1npom/EjJA6uxbA3grjEpbs/7EUdcbvW2I+dEq+3x649TnKH2nscM8WYzZohzScQD VdOIar7XyX0PaviT5n4MyfguwO2OGSZ3LIJ1ELaR5xxKNl9c/gd5/4CMNhuyrkQFnhY4gDQv VKSq3LdReTtyTBQ/OIEKceaLUcUUt/Fi+66aE8kdT8DhDE1ujF7a9ED1vFDNFVw4NtNsfE7+ KCJJKuMt23qBHikwa2YKb4RBEPPggFlKRCjtpoDpnrxJ24KmAlxsCmRN8t5L78lGSctfCEVJ XJVpASIgKvgjX+q9DoDNzxPyDLZv8PXJLk5rOc7T6lnCWmRd5yqEKfJ/BwAAAAAAAA== --------------ms030803070108020903050607--

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012