openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

(ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 15 Sep '08

15 Sep '08

Full_Name: Aaron Richton Version: RE24 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) Rare connection.c assertion during test008s of RE24. Here are three different examples: t@6 (l@6) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@6 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff76bfeb30, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x100427478, 0x100427480), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff76bfefec), line 871 in "connection.c" [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" [7] monitor_entry_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 90 in "entry.c" [8] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c03d8, sub = 1), line 53 in "search.c" [9] monitor_send_children(op = 0x103a359b0, rs = 0xffffffff76bff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 245 in "search.c" [11] fe_op_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 366 in "search.c" [12] do_search(op = 0x103a359b0, rs = 0xffffffff76bff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff76bffc20, arg_v = 0x103a359b0), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff76bffc20, argv = 0xe), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@18 (l@18) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@18 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff6dbfeb20, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x16, 0x1006b9cd8, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff6dbff02c), line 871 in "connection.c" [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 187 in "rww.c" [7] monitor_entry_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = 0x1005c1b98), line 59 in "entry.c" [8] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [9] monitor_send_children(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [10] monitor_back_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 245 in "search.c" [11] fe_op_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 366 in "search.c" [12] do_search(op = 0x102c3dd70, rs = 0xffffffff6dbff998), line 217 in "search.c" [13] connection_operation(ctx = 0xffffffff6dbffc20, arg_v = 0x102c3dd70), line 1084 in "connection.c" [14] connection_read_thread(ctx = 0xffffffff6dbffc20, argv = 0x1e), line 1211 in "connection.c" [15] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" t@3 (l@3) terminated by signal ABRT (Abort) 0xffffffff7f0a8d4c: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xffffffff7f0a8d5c Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); current thread: t@3 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff78ffea50, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x62, 0x0, 0x62, 0x7efefeff, 0x81010100, 0xff00), at 0xffffffff7f03e688 [4] __assert(0x100298090, 0x1002980c8, 0x367, 0x0, 0x0, 0x0), at 0xffffffff7f03e98c =>[5] connection_next(c = (nil), index = 0xffffffff78fff02c), line 871 in "connection.c" [6] connection_first(index = 0xffffffff78fff02c), line 829 in "connection.c" [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 185 in "rww.c" [8] monitor_entry_update(op = 0x100922640, rs = 0xffffffff78fff998, e = 0x1005c1b98), line 59 in "entry.c" [9] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0748, sub = 1), line 88 in "search.c" [10] monitor_send_children(op = 0x100922640, rs = 0xffffffff78fff998, e_parent = 0x1005c0338, sub = 1), line 123 in "search.c" [11] monitor_back_search(op = 0x100922640, rs = 0xffffffff78fff998), line 245 in "search.c" [12] fe_op_search(op = 0x100922640, rs = 0xffffffff78fff998), line 366 in "search.c" [13] do_search(op = 0x100922640, rs = 0xffffffff78fff998), line 217 in "search.c" [14] connection_operation(ctx = 0xffffffff78fffc20, arg_v = 0x100922640), line 1084 in "connection.c" [15] connection_read_thread(ctx = 0xffffffff78fffc20, argv = 0x22), line 1211 in "connection.c" [16] ldap_int_thread_pool_wrapper(xpool = 0x100502250), line 663 in "tpool.c" I have the testrun directories from each of these runs, if desired.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 15 Sep '08

15 Sep '08

I have uploaded a patch that incorporates yours into the code as after applying my fixes to certificate stuff and the implementation of certificateList matching as of last night (ITS#5700). I have modified your contribution to reflect the functionalities I have added to certificate handling in order to minimize code duplication. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2008-09-15-pmi.patch> Note that the OIDs used in the above patch are from OpenLDAP's development arc, but I didn't register them yet, because I first want to be sure there are no official OIDs for those syntaxes yet. The patch also includes the complete schema (objectClasses and attributeTypes) concerning PMI as of X.509. I'll commit it as soon as I get some feedback about your copyright notice and OID registration. In the meanwhile, please test. 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#5673) Replication delete problem
by ghenry＠OpenLDAP.org 15 Sep '08

15 Sep '08

Miguel Jinez wrote: > I was making a test deleting 8600 users in my ldap DIT, but I think > meanwhile Master A perform the actions the synchronization doesn't > respect the hierachy and deletes fathers but not his sons. > Why I said that, because I try to upload again the users and in some > cases they alredy exist I think I recall an ITS for this. Will check. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5700) [enhancement] add support for certificateListExactMatch (RFC4523)
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando About to commit... p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 14 Sep '08

14 Sep '08

Other comments: - you seem to have hijacked the OIDs for the AttributeCertificate and attributeCertificateExactAssertion syntaxes. I'll generate two under the OpenLDAP experimental arc, unless anyone can point me to any officially assigned. I don't think so, as the only document I could locate on the topic is a draft expired in 2001 (draft-ietf-pkix-ldap-schema), with no OID assigned by IANA. - as far as I can understand, the attributeCertificateExactAssertion allows more options; a fairly generic case would be { serialNumber 'dd'H, issuer { issuerName { directoryName:rdnSequence:"cn=y" }, -- optional baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" }, issuerUID "<value>" -- optional }, -- optional objectDigestInfo { ... } -- optional } } while your implementation requires { serialNumber 'dd'H, issuer { baseCertificateID { serial '1d'H, issuer { directoryName:rdnSequence:"cn=z" } } } } nothing more and nothing less. If I'm correct, your implementation would pose some interoperability issues; yet, it represents a good starting point, given the absence of any standard track specification of PMI. 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#5695) AC syntax in OpenLDAP
by ando＠sys-net.it 13 Sep '08

13 Sep '08

tamburo(a)studenti.unina.it wrote: > Sorry for error the correct link is > http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1… > Thanks for the contribution. I gave a look at it, and seems to be fine, although I need to check something with X.509. I wonder if and how much you tested it, since while playing with it I found what I believe is a severe issue in lutil_str2bin(), which is used also in your code... (see ITS#5699). I also have a concern with respect to the IPR declaration on top of your patch, though. You state: > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Luca Tamburo at ICAR, Branch of Naples, > Italy. Luca Tamburo has not assigned rights and/or interest in this > work to any party. I, Giovanni Schmid, project manager at ICAR, am > authorized by Luca Tamburo, my employer, to release this work under > the following terms. It sounds like you are authorizing Giovanni Schmid, project manager at ICAR, to release your work, or something like that? I think you should clarify it a little bit. In any case, I'd leave all issues about IPR to the OpenLDAP foundation; as soon as it's clarified, I'll commit your patch (with some modifications). 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

(ITS#5699) lutil_str2bin fails for certain hex values
by ando＠sys-net.it 13 Sep '08

13 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando When passed "'E31ED28BA060532F'H", lutil_str2bin() fails because calls strtol() passing it the first 8 hex digits ("E31ED28B"), which is larger than the largest long it can handle. Not sure about how to fix it (probably, it should use strtoul instead). p.

1 0

Re: (ITS#5695) AC syntax in OpenLDAP
by tamburo＠studenti.unina.it 12 Sep '08

12 Sep '08

Sorry for error the correct link is http://www.studenti.unina.it/~tamburo/tesi/openldap/Luca-Tamburo-AC-08-09-1… I have a problem with public ftp. Luca Tamburo ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

1 0

(ITS#5698) slapd crashes after trying to add an invalid database entry
by rhafer＠suse.de 12 Sep '08

12 Sep '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.152.188) slapd segfaults after trying to add an invalid database entry to cn=config. E.g. I used this one to reproduce the problem (substring index is not allowed for objectclass): dn: olcdatabase=hdb,cn=config objectclass: olchdbconfig olcdatabase: hdb olcsuffix: cn=test olcdbdirectory: /tmp olcdbcheckpoint: 3 5 olcdbindex: objectclass sub It crashes in the checkpoint runqueue task, which it seems has not be removed after the failed ADD operation: #0 0x000000000052303e in hdb_checkpoint (ctx=0x41f81dd0, arg=0xb1bfb0) at config.c:181 #1 0x00007f3cbcdd502f in ldap_int_thread_pool_wrapper (xpool=0x8ec640) at ../../../libraries/libldap_r/tpool.c:663 #2 0x00007f3cb9d73040 in start_thread () from /lib64/libpthread.so.0 #3 0x00007f3cb9ae60cd in clone () from /lib64/libc.so.6 A fix is on the way to HEAD.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 11 Sep '08

11 Sep '08

This is a cryptographically signed message in MIME format. --------------ms030502050400050400000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following is from the person who developed the patch: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Robert Relyea am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --------------ms030502050400050400000609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEFcdcRwRB8xs7lDIZBO/bfowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTIwNDE2MzM1OVoX DTA4MTIwMzE2MzM1OVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANpEUJJ++jpsDRmNt7cla8gygzXXoOHCPCubSxG0juJoxS/4F1UiyVSy0Gzb C5lVZemRenB+G389Ai11jLKp97S1abeQII26poIkjvYJCjyO92SJNFvb8mz6bkBW9NcH2zBt odjoeCvdlKuwxg1IX/kYsmz4lirjIVPFPSyqx7jgYhuNpjfR3oUuNRLx5Y6i9Ep+1AmTkoWx NNwMNFwRUOh78z/Gvh9exCB8Xldd58egHfYluBraFi5IgkGQneI4+VyFrNwwX1XtjI2EmDrO HnMTZGnkYBH5L6b54bMkIKxMmZrmdzcyQ0JLbz2GZqKo5BUaN4M1M2kTCy0HbKOlhZECAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBAELh1VaZchhZmlX93Wmbu8loeXNOP5/RRJVHCgom1N7g4YZBcBwM 1bmoo5b9gK3IPrPxZu2zYuyxwveNM0KdmaYtLzWiStJyifMDb8FtMNvVc5oewQK5tnDUw3dG MH/TxiE/hEZiRjAVylPiwzq47PjVPIM87Rek8hROvCkaEO6hMIIC4DCCAkmgAwIBAgIQVx1x HBEHzGzuUMhkE79t+jANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDcxMjA0MTYzMzU5WhcNMDgxMjAzMTYzMzU5WjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kRQkn76 OmwNGY23tyVryDKDNdeg4cI8K5tLEbSO4mjFL/gXVSLJVLLQbNsLmVVl6ZF6cH4bfz0CLXWM sqn3tLVpt5AgjbqmgiSO9gkKPI73ZIk0W9vybPpuQFb01wfbMG2h2Oh4K92Uq7DGDUhf+Riy bPiWKuMhU8U9LKrHuOBiG42mN9HehS41EvHljqL0Sn7UCZOShbE03Aw0XBFQ6HvzP8a+H17E IHxeV13nx6Ad9iW4GtoWLkiCQZCd4jj5XIWs3DBfVe2MjYSYOs4ecxNkaeRgEfkvpvnhsyQg rEyZmuZ3NzJDQktvPYZmoqjkFRo3gzUzaRMLLQdso6WFkQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA QuHVVplyGFmaVf3daZu7yWh5c04/n9FElUcKCibU3uDhhkFwHAzVuaijlv2Arcg+s/Fm7bNi 7LHC940zQp2Zpi0vNaJK0nKJ8wNvwW0w29Vzmh7BArm2cNTDd0Ywf9PGIT+ERmJGMBXKU+LD Orjs+NU8gzztF6TyFE68KRoQ7qEwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFcd cRwRB8xs7lDIZBO/bfowCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDgwOTEyMDE1ODU5WjAjBgkqhkiG9w0BCQQxFgQUia3iQGIt gUDrIWJABkXGXDP2uO0wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQVx1xHBEHzGzuUMhkE79t+jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVx1xHBEHzGzu UMhkE79t+jANBgkqhkiG9w0BAQEFAASCAQCxIfkCUbjvfwVycRf8HdSbkjTeYjkd18E9+gHw 6Lvbs3UYzlWj8yZSynu15jPPg6KhqwX3kG7mVJybQtGpVLt5PMjp+OgIspDWIHOk5bhw/CW7 0OqtZwEVHH1tCIPKIeCHWlRq367W6DKy0SUs843IRpPa8o1YgxLGIIhp4BBxrdx6/Ep7WUtk PvA1mDRcrVQceTzJoHnwe56bSNXnkCrsYA94NAd4NFmRSoE8JVeWWgBBbgI3IEEvINTC+pM3 nbh1gOxxBMFtw2JFufrWnCGnXyVKy5rfPL8BPI3ul6N1AurDhTNbAXOHJkz+OZLOlMxyKJA9 s7ua54QILncIuSWzAAAAAAAA --------------ms030502050400050400000609--

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