openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#7823) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

Full_Name: Frederic POISSON Version: 2.4.39 OS: Linux RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hello, I have a Segmentation fault while i'm updating the value of olcDbMaxSize parameter to a number inside olcDatabase={1}mdb,cn=config. The result of a gdb backtrace show this error : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42499940 (LWP 31424)] 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, conn=0x18ab2a50) at ppolicy.c:1260 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { The ldif for the modification is : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 20737418240 I will push onto FTP the full log of the backtrace, the cn=config.ldif from slapcat. Hoping it could help for resolution. Regards,

1 0

(ITS#7822) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

1 0

(ITS#7821) address of strcasecmp in ldapsearch.c
by heiko.nardmann＠itechnical.de 20 Mar '14

20 Mar '14

Full_Name: Heiko Nardmann Version: 2.4.39 OS: MinGW32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:a60:f08d:1:159e:f75f:8f0:44f1) In clients/tools/ldapsearch.c the address of 'strcasecmp' is taken (inside 'dosearch()') around line 1455. That means that 'strcasecmp' is exported as an undefined symbol into ldapsearch.o even if 'strcasecmp' is declared as 'always_inline'. MinGW is such a platform which offers 'strcasecmp' by providing an inline version of 'strcasecmp' (redirecting it to 'stricmp'). So this taking of an address breaks linking. Workaround: before 'dosearch()' I place a local wrapper: static int local_strcasecmp(const char *s1, const char *s2) { return strcasecmp(s1, s2); } and inside 'dosearch' instead of if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, strcasecmp ); } I now have if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, local_strcasecmp ); } Some options to really solve that issue: 1) use my approach for all platforms. 2) change autoconf stuff to detect whether 'strcasecmp' is just inlined (MinGW) or a "real" function (other platforms). Thx in advance! Heiko

1 0

Re: (ITS#7587) slapd crashes when using pcache overlay applied to a translucent proxy
by hyc＠symas.com 18 Mar '14

18 Mar '14

amoneger(a)cisco.com wrote: > Full_Name: Alex > Version: 2.4.35 > OS: Centos 6.3 (2.6.32-279.el6.x86_64 #1 SMP) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > When using the pcache overlay over a translucent proxy, the slapd daemon crashes > after the second LDAP request which misses the cache. For example, the following > requests will trigger the issue. The important part is to miss the cache. > Assuming nothing is cached for the aaaa and bbbb uid, the following request will > trigger the issue (172.16.206.156 being the openldap server): Thanks for the report, this is now fixed in git master. > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=aaaa" uid > st > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=bbbb" uid > st > > Whether aaaa and bbbb exist or not does not matter. > > The following config is used: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/misc.schema > include /usr/local/etc/openldap/schema/nis.schema > > moduleload pcache.la > moduleload translucent.la > > database bdb > suffix "o=xxxx" > #checkpoint 1024 15 > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > overlay translucent > translucent_local uidNumber,gidNumber,homeDirectory,loginShell > translucent_strict > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > uri ldap://zzzz/ > #tls ldaps tls_reqcert=demand > tls_cacert=/usr/local/etc/openldap/certs/Cisco_ca_chain > overlay pcache > pcache bdb 10000 1 50 100 > pcacheAttrset 0 * > pcacheTemplate (uid=) 0 3600 > pcacheBind (uid=) 0 1800 sub ou=yyyy,o=xxxx > pcacheOffline TRUE > pcachePersist TRUE > pcacheValidate FALSE > directory /var/cache/ldap > cachesize 1000 > index pcacheQueryid eq > > The crash seems to be caused by a SIGABRT which is raised by libc free() due to > a double free. Here is the traceback: > Breakpoint 2, 0x000000312aa33f10 in abort () from /lib64/libc.so.6 > (gdb) c > Continuing. > > Program received signal SIGABRT, Aborted. > 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > #1 0x000000312aa34085 in abort () from /lib64/libc.so.6 > #2 0x000000312aa707b7 in __libc_message () from /lib64/libc.so.6 > #3 0x000000312aa760e6 in malloc_printerr () from /lib64/libc.so.6 > #4 0x000000000042391e in do_search (op=0x7f135c000b80, rs=0x7f1366764930) at > search.c:263 > #5 0x0000000000421449 in connection_operation (ctx=0x7f1366764a90, > arg_v=0x7f135c000b80) at connection.c:1155 > #6 0x0000000000421c25 in connection_read_thread (ctx=0x7f1366764a90, > argv=<value optimized out>) at connection.c:1291 > #7 0x00000000005601f0 in ldap_int_thread_pool_wrapper (xpool=0x1f42770) at > tpool.c:688 > #8 0x000000312b207851 in start_thread () from /lib64/libpthread.so.0 > #9 0x000000312aae890d in clone () from /lib64/libc.so.6 > > I was unable to track back the particular piece of code triggering the double > free, but the same pointer p is freed twice by ber_memfree_x() in memory.c: > > (gdb) delete 3 > (gdb) break search.c:263 > Breakpoint 4 at 0x5645df: file search.c, line 263. > (gdb) c > Continuing. > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print p > $1 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000001 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > (gdb) c > Continuing. > [New Thread 0x7fa561994700 (LWP 5823)] > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print P > No symbol "P" in current context. > (gdb) print p > $2 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000000 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > > So the same pointer is being freed twice by the 2 connections which miss the > cache. I'm unable to figure out who is responsible for that call though, but the > same op->ors_attrs is freed by do_search(): > > if ( op->ors_attrs != NULL ) { > op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > > Parameters seem correct in both cases: > (gdb) print op->o_hdr->oh_tmpmfuncs->bmf_free > $12 = (BER_MEMFREE_FN *) 0x4733f0 <slap_sl_free> > (gdb) print op->o_request.oq_search.rs_attrs > $15 = (AttributeName *) 0x1f85a10 > > The call is done via connection_operation(), but that code part is a bit above > my head, so I'm unable to track this further. > > I thought this could be due to a threading problem, but building slapd with > --with-threads=no does not make a difference. > > I tried uploading the core dump to your ftp server, but seems like there is an > issue with ftp.openldap.org > [root@centos63 tmp]# ftp ftp.openldap.org > Trying 204.152.186.57... > Connected to ftp.openldap.org (204.152.186.57). > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (ftp.openldap.org:cisco): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> binary > 200 Type set to I. > ftp> put core-slapd-6-55-55-26548-1368063267 > local: core-slapd-6-55-55-26548-1368063267 remote: > core-slapd-6-55-55-26548-1368063267 > 227 Entering Passive Mode (204,152,186,57,242,33) > 553 core-slapd-6-55-55-26548-1368063267: No space left on device. > > Let me know if you need anything. I can provide further debugs or cores. I'm > also happy to try things out. > > Cheers, > Alex > > -- -- 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#7723
by hyc＠symas.com 18 Mar '14

18 Mar '14

michael(a)stroeder.com wrote: > Could anybody please review the patch Jan provided in his last follow-up? > > http://www.openldap.org/its/index.cgi?findid=7723#followup9 > > Anythin wrong with his reference count fix? > > We are getting occasional seg faults in slapo-rwm which are very hard to > reproduce and therefore are considering this patch. Looks OK to me, committed to master. Please report back any positive/negative results. -- -- 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

ITS#7723
by michael＠stroeder.com 18 Mar '14

18 Mar '14

Could anybody please review the patch Jan provided in his last follow-up? http://www.openldap.org/its/index.cgi?findid=7723#followup9 Anythin wrong with his reference count fix? We are getting occasional seg faults in slapo-rwm which are very hard to reproduce and therefore are considering this patch. Ciao, Michael.

1 0

Re: (ITS#7820) slapo-constraint falsely allows add with count 1
by pierangelo.masarati＠polimi.it 15 Mar '14

15 Mar '14

On 03/15/2014 05:38 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.39 > OS: not relevant > URL: > Submission from: (NULL) (79.219.107.130) > > > Not sure whether this is a regression caused by the fix for ITS#7773. > > Given this constraint: > > constraint_attribute > uid > count 1 > restrict="ldap:///ou=example??sub?(objectClass=account)" > > One can still add two 'uid' values when sending an add request like this: > > dn: uid=test1,ou=example > changetype: add > objectClass: account > uid: test2 > [..] > > Generally I don't like this magic of accepting both attribute values from DN and > entry. :-/ Indeed, the check (and magic) of adding distinguished value(s) to entry occurs during entry_naming_check(), which occurs during entry_schema_check(), which occurs in the backend add operations, right after overlays had a chance to look at the entry. 2 approaches: a) anticipate naming check b) duplicate naming check in slapo-constraint (b) is a waste, but "localized"; not sure what would be the side effects of (a). p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7820) slapo-constraint falsely allows add with count 1
by michael＠stroeder.com 15 Mar '14

15 Mar '14

Full_Name: Version: 2.4.39 OS: not relevant URL: Submission from: (NULL) (79.219.107.130) Not sure whether this is a regression caused by the fix for ITS#7773. Given this constraint: constraint_attribute uid count 1 restrict="ldap:///ou=example??sub?(objectClass=account)" One can still add two 'uid' values when sending an add request like this: dn: uid=test1,ou=example changetype: add objectClass: account uid: test2 [..] Generally I don't like this magic of accepting both attribute values from DN and entry. :-/

1 0

Re: (ITS#7673) rwm and bad ACL evaluation
by hyc＠symas.com 15 Mar '14

15 Mar '14

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. Is it really necessary to sign your emails to the ITS? The PKCS7 signature is longer than the message text. > --------------ms020400000305090906010704 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Mosemann, Russell wrote: >>> Did you already try with this? >>> >>> rwm-drop-unrequested-attrs no >> =20 >> If you look through the messages >> (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see tha= > t the >> same suggestion was made by Pierangelo Masarati 6 months ago in followu= > p 5. >> My response in followup 6 was that it doesn't work. A quick test indica= > tes >> that it still does not work in 2.4.39. > > I had a similar issue myself before: > > http://www.openldap.org/its/index.cgi?findid=3D7495 > > Using extra_attrs as suggested by Hallvard gave seg fault as result. > Did not investigate it further though. > > Using slapo-rwm is a pain. One will hit many seg faults. There are quite a few open bug reports against slapo-rwm. Patches welcome. > > Ciao, Michael. -- -- 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#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 15 Mar '14

15 Mar '14

This is a cryptographically signed message in MIME format. --------------ms020400000305090906010704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mosemann, Russell wrote: >> Did you already try with this? >> >> rwm-drop-unrequested-attrs no >=20 > If you look through the messages > (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see tha= t the > same suggestion was made by Pierangelo Masarati 6 months ago in followu= p 5. > My response in followup 6 was that it doesn't work. A quick test indica= tes > that it still does not work in 2.4.39. I had a similar issue myself before: http://www.openldap.org/its/index.cgi?findid=3D7495 Using extra_attrs as suggested by Hallvard gave seg fault as result. Did not investigate it further though. Using slapo-rwm is a pain. One will hit many seg faults. Ciao, Michael. --------------ms020400000305090906010704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MTEwMDAyWjAj BgkqhkiG9w0BCQQxFgQUUSa2ArlMv5dRmzJlQRq5PcrRHkUwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAvyDf1DHX6lO5GY/rJUE8fG+SMoafXeCK H7gMAa2TDdkjvgjPDrfVSXHu+c0SGwayuluYm+A1NLPrJ0yuDD056fBFEBle/2mf6iD/AUC4 WqoLNLNtNAXomiyHoztxopV83jzbbA4xCHMvPr9PRtbtrr+uTmZGjOcxuEBj+0K+nUM4xFAU OFWve6ySjrFpGj/7JfTkgMq2hqlkmLn6v9VgqqldkY5lEEKDbS3pFPyi+cTpB8EGh5uANGv9 q2ga1fkbkSBrMHEntQdvdT/puvVPZPJxgtL7ooTIXvmCQVMGnUEtOylUgYpCpCUHq3LXJ7dE DM2tyDJ3+1IRihV81j/h0AAAAAAAAA== --------------ms020400000305090906010704--

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