openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6198) Authorization for extensions
by hyc＠symas.com 07 Jul '09

07 Jul '09

Michael Ströder wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD/2.5 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc >> >> >> The access control mechanism needs to be extended to control actions, not just >> objects, to control who may use various LDAP Controls and Extended Operations. > > +1 > >> E.g. >> access to control=<oid> by<who> >> access to op=<operation or oid> by<who> > ^^^^^^^^^ > What is "operation" supposed to be? I'd prefer only to allow "oid" since > OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ugh, no. There's no way any sysadmin is going to remember what each OID means. Each exop will be given a "friendly name" like WhoAmI, ModifyPwd, etc. Don't make the same mistake the original LDAP implementers did - numeric OIDs are for machine consumption only; they should always be mapped to mnemonic names for use by humans. (Technically they should be mapped to *localized* names; obviously the names were not intended to be part of the protocol specification. This is another glaring flaw in the LDAP specifications...) -- -- 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#6198) Authorization for extensions
by michael＠stroeder.com 07 Jul '09

07 Jul '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/2.5 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > The access control mechanism needs to be extended to control actions, not just > objects, to control who may use various LDAP Controls and Extended Operations. +1 > E.g. > access to control=<oid> by <who> > access to op=<operation or oid> by <who> ^^^^^^^^^ What is "operation" supposed to be? I'd prefer only to allow "oid" since OIDs are the only identifiers clearly specified in RFCs and I-Ds. Ciao, Michael.

1 0

(ITS#6198) Authorization for extensions
by hyc＠OpenLDAP.org 07 Jul '09

07 Jul '09

Full_Name: Howard Chu Version: HEAD/2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc The access control mechanism needs to be extended to control actions, not just objects, to control who may use various LDAP Controls and Extended Operations. E.g. access to control=<oid> by <who> access to op=<operation or oid> by <who> Perhaps the control= / op= specifier should be usable in combination with the other <what> specifiers; I haven't thought too deeply about it. It only makes sense in limited contexts, since various extensions may not even affect any particular directory object.

1 0

Re: (ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by hyc＠symas.com 07 Jul '09

07 Jul '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > send_ldap_ber() has a suspicious-looking waitloop doing this: > > if ( ldap_pvt_thread_mutex_trylock(&conn->c_mutex )) { > ldap_pvt_thread_mutex_unlock(&conn->c_write1_mutex ); > ldap_pvt_thread_mutex_lock(&conn->c_write1_mutex ); > > Unlock does not mean a thread waiting for c_write1_mutex will acquire > it immediately. Such a thread may have to wait until it is scheduled, > at which time the looping thread has locked the mutex again. This code has changed in HEAD. Closing this ITS. > > On the Linux box on my desk, a pure unlock-lock loop goes through > 50000-100000 iterations before another thread waiting for the lock > acquires it. OTOH, on a heavily used box it takes ~50 iterations. > > A sched_yield() between the unlock and lock reduces #iterations to 1. > No idea if that is the right solution, nor how serious the problem is. > > The lock/unlock statements themselves are from result.c rev 1.323, > but then with some more locking between them which disappeared in > later revisions. > > My lock-unlock test program: > > #include<pthread.h> > #include<sched.h> > #include<stdio.h> > #include<stdlib.h> > #include<sys/select.h> > > static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; > static unsigned count; > > static void *waiter(void *arg) { > pthread_mutex_lock(&m); > printf("Locked after %u iterations.\n", count); > exit(0); > } > > int main() { > pthread_t t; > pthread_mutex_lock(&m); > pthread_create(&t, NULL, waiter, NULL); > select(0, NULL, NULL, NULL,&(struct timeval){0, 100000}); > for (count = 1 ;; ++count) { > pthread_mutex_unlock(&m); > pthread_mutex_lock(&m); > } > } > > -- -- 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#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > Hi, > > Sorry for the HTML email. > > With the debug symbols there's an assert that fails in slapd_clr_write > method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): Thanks. The hang should really be fixed now. :P Please re-sync RE24 and test again. Thank you! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 06 Jul '09

06 Jul '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_err2string() and ldap_perror() use ldap_int_error(), which walks an array looking for the result code. That's silly, I'll replace it with a macroized switch statement unless someone protests. Compilers will usually turn that into a binary search or better. A prebuilt hash would be better, but would complicate source code maintenance. I might do that someday if anyone cares. Also don't see why ldap_perror() outputs a less informative error string than ldap_err2string() for unknown result codes. ldap_perror says "unknown result code" (with lowercase initial), while err2string says "Unknown <API error/(extension) error/(private extension) error/error". Looks like ldap_perror() could be improved by calling ldap_err2string(). (Yes I know ldap_perror is deprecated. See if I care, I like it.)

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 06 Jul '09

06 Jul '09

Hi, Sorry for the HTML email. With the debug symbols there's an assert that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): (gdb) bt #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out>, wake=3D0) at daemon.c:939 #4 0x00000000004422dc in connection_write (s=3D403) at connection.c:1855 #5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized out>) at daemon.c:2567 #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Without debug symbols, using gdb to attach to the process it can be seen all the threads hang on the pthread_cond_wait in send_ldap_ber method in result.c. Best regards. On Mon, Jul 6, 2009 at 7:29 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > >> --001636c5b1542f27b3046e045d1b >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: 7bit >> >>> >>> >>> Although with a slapd without debug symbols it works ok, there's an >>> assert that fails in slapd_clr_write method, ("assert( >>> SLAP_SOCK_IS_ACTIVE( s ))"): >>> >>> (gdb) bt >>> # 0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 >>> # 1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 >>> # 2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 >>> # 3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out>, >>> # wake=3D0) >>> at daemon.c:939 >>> # 4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 >>> # 5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized out= >) >>> # at >>> daemon.c:2567 >>> # 6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 >>> # 7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 >>> # 8 0x0000000000000000 in ?? () >>> >>> >> Hello, >> >> The problem still reproduces, all connection hangups after a weekend >> overloading the server.. > > Can you please stop writing HTML email? thanks. ;) > > Also, can you please re-compile with debugging symbols available, and pro= vide a backtrace of the hung server? :) > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =C2=A0the leader in open source messaging and collaboration

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > --001636c5b1542f27b3046e045d1b > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > >> >> >> Although with a slapd without debug symbols it works ok, there's an >> assert that fails in slapd_clr_write method, ("assert( >> SLAP_SOCK_IS_ACTIVE( s ))"): >> >> (gdb) bt >> # 0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 >> # 1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 >> # 2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 >> # 3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, >> # wake=0) >> at daemon.c:939 >> # 4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 >> # 5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) >> # at >> daemon.c:2567 >> # 6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 >> # 7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 >> # 8 0x0000000000000000 in ?? () >> >> > Hello, > > The problem still reproduces, all connection hangups after a weekend > overloading the server.. Can you please stop writing HTML email? thanks. ;) Also, can you please re-compile with debugging symbols available, and provide a backtrace of the hung server? :) Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 06 Jul '09

06 Jul '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms020502060206020809020001 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hallvard B Furuseth wrote: >> The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd >> and OpenSSL: >> >> passwd.c:660: error: expected declaration specifiers or '...' before '(' token >> passwd.c:660: error: expected declaration specifiers or '...' before '&' token >> passwd.c:661: error: conflicting types for 'DES_set_key' >> /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' >> >> Preprocessor output for passwd.c shows that this in passwd.c: >> static void >> des_set_key( des_key *key, unsigned char *keyData) { ... } >> conflicts with this macro from /usr/include/openssl/des_old.h: >> #define des_set_key(k,ks) DES_set_key((k),&(ks)) >> which when expanded tries to conflict with this prototype from >> /usr/include/openssl/des.h: >> int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); >> >> > I think Howard was going to omit the passwd.c changes. I applied the DES changes, and dropped the SHA1 changes. The version now in HEAD also avoids this naming conflict. -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 06 Jul '09

06 Jul '09

This is a cryptographically signed message in MIME format. --------------ms020502060206020809020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hallvard B Furuseth wrote: > The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd > and OpenSSL: > > passwd.c:660: error: expected declaration specifiers or '...' before '(' token > passwd.c:660: error: expected declaration specifiers or '...' before '&' token > passwd.c:661: error: conflicting types for 'DES_set_key' > /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' > > Preprocessor output for passwd.c shows that this in passwd.c: > static void > des_set_key( des_key *key, unsigned char *keyData) { ... } > conflicts with this macro from /usr/include/openssl/des_old.h: > #define des_set_key(k,ks) DES_set_key((k),&(ks)) > which when expanded tries to conflict with this prototype from > /usr/include/openssl/des.h: > int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); > > I think Howard was going to omit the passwd.c changes. --------------ms020502060206020809020001 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 AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/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 THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2MTUwNTE5WjAjBgkqhkiG9w0BCQQxFgQUEhRXD3S8 y7XRMK4qRv/cvAGaP7MwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQAsIFbd928YyHFnVXHDB6vIbO0MX7chq9nDKj4l HeCgXft1yEARDQ8ra3s4hApdNnE1PicCx2yrmPuQivjRo7tsZ2CCIBvH8aIrbxhEa0ZJ2USC pTgNIG2lk1cFiQ7c09NZSFwuU+s0Vp5M7b+U68VkJ+UV1WLeslYJT3QubNvz91C5uVeldQQ/ gPjbKVS74MN1bCDtPfHMIkhvSSR4Fmv8/89ZEAjYHE4m02ppr4ij8foA62jdESzJ2RXDdl7q spoxNwUqBKKJnlO11+40BXlWH2Vr+ssPoyEczDwfYbQkYnUNmgQKaNjp2Bs8sZAj0CpdhRI/ mhCTUoQQXZHSVBOPAAAAAAAA --------------ms020502060206020809020001--

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