openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

On 07/07/15 21:44, h.b.furuseth(a)usit.uio.no wrote: > My feeling is that this is a quirk the user should not need to > know about, and it's cleaner to sy r rather than to document it. ...cleaner to sync rather than...

1 0

(ITS#8191) mdb_txn_commit(empty txn) does not sync
by h.b.furuseth＠usit.uio.no 07 Jul '15

07 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_txn_commit(txn which made no changes) does not mdb_env_sync(), but lmdb.h says several times that Commit flushes buffers to disk. My feeling is that this is a quirk the user should not need to know about, and it's cleaner to sy r rather than to document it. OTOH I don't know if "fast commit of no-change txns" is a feature which someone expects to work, and if sync can be expensive even when there is no new data to flush. (I don't know what BDB does.)

1 0

(ITS#8190) LMDB cursor bug
by hyc＠openldap.org 07 Jul '15

07 Jul '15

Full_Name: Howard Chu Version: LMDB 0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.234.0) Submitted by: hyc In mdb_cursor_set(SET_RANGE) a call to mdb_cursor_sibling is used if the matching key wasn't found on the current page. If this call fails, the EOF flag should be set on the cursor but isn't. Subsequent attempts to call mdb_cursor_next() will read garbage data. A fix is coming shortly.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

On 07/06/2015 01:30 PM, Michael Ströder wrote: > Consider that you are under on-going attack with many different > accounts affected by the lockout treshold. Then you cannot simply wait > for pwdFailureCountInterval seconds because your system is changing > all the time. > > Such a situation is a real world scenario. Ok -- I'm probably not understanding enough about your particular scenario to fully appreciate the concerns that you express. But I think there could be ways to address them in this enhancement -- for instance, by adding optional parameter(s) like ppolicy_purge_failures <nfailures> and/or ppolicy_purge_olderthan <timestamp>, which could then be configured to accommodate the scenario you describe. At this point, I'll think I'll leave it up to the OpenLDAP developers as to how they want to proceed on this, and/or to ask for more information. Thanks for the discussion Michael. Regards, -Kartik

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 06 Jul '15

06 Jul '15

Kartik Subbarao wrote: > On 07/06/2015 12:25 PM, Michael Str=C3=B6der wrote: >> Hmm, still have some doubts: If you want to raise the failure count li= mit >> later you would automatically unlock some accounts you don't want to u= nlock >> at this particular point in time. >=20 > Two thoughts on this: >=20 > 1) If you raise the failure count limit, aren't you inherently making a= > decision to be more lenient in your policy, and thereby accepting that = some > accounts are not going to be locked out as fast as they might be under = the > previous policy? Yes, there could be a situation where you want to deliberately relax the lockout policy after carefully considering various security aspects of yo= ur particular deployment. > It seems to me that any "inadvertent" unlocking due to purged > pwdFailureTime values could be embraced under this general umbrella of = leniency. No! You set a new lockout limit and most people would expect this to be s= olely effective on user accounts which did not reach the new limit yet. > 2) If pwdFailureCountInterval is set to some reasonably low number, the= n this > whole concern becomes moot: Just wait for pwdFailureCountInterval secon= ds > after you decide to change the configuration, before actually changing = the > configuration :-) Consider that you are under on-going attack with many different accounts affected by the lockout treshold. Then you cannot simply wait for pwdFailureCountInterval seconds because your system is changing all the t= ime. Such a situation is a real world scenario. =3D> @OpenLDAP developers: leave as is! Ciao, Michael. P.S.: I'm not a big fan of password lockout anyway because it's misconfig= ured too often because of brain-dead comapny security policies.

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

Thanks for the heads-up Quanah. Looks like you've found a serious problem with multi-master replication, good to know about. In my case, we're just using single-master replication, so we're able to dodge the problem you describe for the time being. Just to clarify though -- once ITS#8125 is resolved, this enhancement shouldn't pose any additional problems for MMR sites, right? Thanks, -Kartik On 07/06/2015 12:18 PM, Quanah Gibson-Mount wrote: > I would note that: > > IF using delta-syncrepl > AND the data values are replicated > AND authentication attempts can occur against different LDAP masters > > You can run into *serious* drift between servers if you try and > implement this, causing endless refresh mode runs that cause the > servers to get further out of sync. See > <http://www.openldap.org/its/index.cgi/?findid=8125>. > > More specifically: > > If a client has (most often) a mobile device with a bad password, and > it's authentication attempts are bouncing between masters, even with > high resolution timestamps, you can get collisions in the delete op > for old values that cannot be reconciled, causing fallback/refresh. > > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

This is a multi-part message in MIME format. --------------000605000401060905080908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/06/2015 12:25 PM, Michael Ströder wrote: > Hmm, still have some doubts: If you want to raise the failure count limit > later you would automatically unlock some accounts you don't want to unlock at this particular point in time. Two thoughts on this: 1) If you raise the failure count limit, aren't you inherently making a decision to be more lenient in your policy, and thereby accepting that some accounts are not going to be locked out as fast as they might be under the previous policy? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency. 2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-) I guess I haven't come across many sites that set pwdMaxFailure, but /don't/ also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-) Regards, -Kartik --------------000605000401060905080908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 07/06/2015 12:25 PM, Michael Ströder wrote: </div> <blockquote cite="mid:559AABDC.8060706@stroeder.com" type="cite"> <pre wrap=""> Hmm, still have some doubts: If you want to raise the failure count limit later you would automatically unlock some accounts you don't want to unlock at this particular point in time. </pre> </blockquote> Two thoughts on this: 1) If you raise the failure count limit, aren't you inherently making a decision to be more lenient in your policy, and thereby accepting that some accounts are not going to be locked out as fast as they might be under the previous policy? It seems to me that any "inadvertent" unlocking due to purged pwdFailureTime values could be embraced under this general umbrella of leniency. 2) If pwdFailureCountInterval is set to some reasonably low number, then this whole concern becomes moot: Just wait for pwdFailureCountInterval seconds after you decide to change the configuration, before actually changing the configuration :-) I guess I haven't come across many sites that set pwdMaxFailure, but don't also set pwdFailureCountInterval. But even in those cases, I think #1 would be valid :-) Regards, -Kartik </body> </html> --------------000605000401060905080908--

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 06 Jul '15

06 Jul '15

This is a multi-part message in MIME format. --------------070603090603020704050207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI for anyone else who is encountering this problem -- here is a script that I wrote as a workaround. It sweeps through all of the pwdFailureTime entries in the directory and deletes stale values greater than $maxvalues. Also set $basedn accordingly. It can be run with '--ldif' to preview the changes, and '--ldap' to actually make the changes. The script binds with SASL EXTERNAL on the ldapi:/// interface, so make sure that the Unix user has the 'manage' privilege for the pwdFailureTime attribute. For example, to enable this for root: access to attrs=pwdFailureTime by dn.base="gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth" manage Regards, -Kartik --------------070603090603020704050207 Content-Type: text/plain; charset=UTF-8; name="pwdfailuretime.pl.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pwdfailuretime.pl.txt" IyEgL3Vzci9iaW4vcGVybAoKIyBQdXJnZSBzdGFsZSBwd2RGYWlsdXJlVGltZSB2YWx1ZXMK CnVzZSBOZXQ6OkxEQVA7CnVzZSBOZXQ6OkxEQVA6OkNvbnRyb2w7CnVzZSBOZXQ6OkxEQVA6 OkxESUY7CnVzZSBBdXRoZW46OlNBU0w7CnVzZSBGY250bCBxdyhMT0NLX0VYIExPQ0tfTkIp Owp1c2UgR2V0b3B0OjpMb25nOwoKdXNlIHN0cmljdDsKCm15ICRiYXNlZG4gPSAiZGM9ZXhh bXBsZSxkYz1jb20iOwpteSAkbWF4dmFsdWVzID0gMTA7CgojIFByZXZlbnQgbXVsdGlwbGUg aW5zdGFuY2VzIGZyb20gcnVubmluZyBhdCB0aGUgc2FtZSB0aW1lCm9wZW4oTE9DS0ZILCAk MCk7IGZsb2NrKExPQ0tGSCwgTE9DS19FWHxMT0NLX05CKSBvciBleGl0IDE7CgpteSAoJGdl bmVyYXRlX2xkaWYsICR1cGRhdGVfbGRhcCk7CkdldE9wdGlvbnMoJ2xkaWYnID0+IFwkZ2Vu ZXJhdGVfbGRpZiwgJ2xkYXAnID0+IFwkdXBkYXRlX2xkYXApOwoKbXkgJGxkaWZvdXQgPSBO ZXQ6OkxEQVA6OkxESUYtPm5ldygnLScsICd3Jyk7CiRsZGlmb3V0LT57Y2hhbmdlfSA9IDE7 Cm15ICRsZGFwID0gTmV0OjpMREFQLT5uZXcoJ2xkYXBpOi8vJykgb3IgZGllICJsZGFwaTog JEBcbiI7Cm15ICRzYXNsID0gQXV0aGVuOjpTQVNMLT5uZXcobWVjaGFuaXNtID0+ICdFWFRF Uk5BTCcpOwpteSAkc2FzbF9jbGllbnQgPSAkc2FzbC0+Y2xpZW50X25ldygnbGRhcCcsICds b2NhbGhvc3QnKTsKJGxkYXAtPmJpbmQodW5kZWYsIHNhc2wgPT4gJHNhc2xfY2xpZW50KTsK bXkgJHJlbGF4ID0gTmV0OjpMREFQOjpDb250cm9sLT5uZXcodHlwZSA9PiAnMS4zLjYuMS40 LjEuNDIwMy42NjYuNS4xMicpOwoKbXkgJG1lc2cgPSAkbGRhcC0+c2VhcmNoKGJhc2UgPT4g JGJhc2VkbiwKCQkJCQkJIGZpbHRlciA9PiAnKHB3ZEZhaWx1cmVUaW1lPSopJywKCQkJCQkJ IGF0dHJzID0+IFsncHdkRmFpbHVyZVRpbWUnXSk7CiRtZXNnLT5jb2RlICYmIGRpZSgkbWVz Zy0+ZXJyb3IgLiAiXG4iKTsKZm9yZWFjaCBteSAkZW50cnkgKCRtZXNnLT5lbnRyaWVzKSB7 CglteSBAdmFsdWVzID0gc29ydCAkZW50cnktPmdldF92YWx1ZSgncHdkRmFpbHVyZXRpbWUn KTsKCW5leHQgaWYgQHZhbHVlcyA8PSAkbWF4dmFsdWVzOwoJIyBTZXQgQHZhbHVlcyB0byB0 aGUgbGlzdCBvZiB2YWx1ZXMgdG8gcHVyZ2UKCXNwbGljZSBAdmFsdWVzLCAtJG1heHZhbHVl czsKCWlmICgkZ2VuZXJhdGVfbGRpZikgewoJCSRlbnRyeS0+ZGVsZXRlKCdwd2RGYWlsdXJl dGltZScgPT4gXEB2YWx1ZXMpOwoJCSRsZGlmb3V0LT53cml0ZV9lbnRyeSgkZW50cnkpOwoJ fQoJaWYgKCR1cGRhdGVfbGRhcCkgewoJCSRsZGFwLT5tb2RpZnkoJGVudHJ5LT5kbiwKCQkJ CQkgIGNvbnRyb2wgPT4gJHJlbGF4LAoJCQkJCSAgZGVsZXRlID0+IHsgcHdkRmFpbHVyZXRp bWUgPT4gXEB2YWx1ZXMgfSk7Cgl9Cn0K --------------070603090603020704050207--

1 0

Re: (ITS#8189) autoconf needed when building release
by michael＠stroeder.com 06 Jul '15

06 Jul '15

checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for Berkeley DB major version in db.h... none configure: error: Unknown Berkeley DB major version in db.h >From config.log: configure:20300: checking db.h usability configure:20300: cc -c -g -O0 -DSLAP_SCHEMA_EXPOSE -DLDAP_COLLECTIVE_ATTRIBUTES -DSLAP_CONFIG_DELETE -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c >&5 configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking db.h presence configure:20300: cc -E -I/usr/include -I/usr/include -I/usr/include -I/usr/include conftest.c configure:20300: $? = 0 configure:20300: result: yes configure:20300: checking for db.h configure:20300: result: yes configure:20311: checking for Berkeley DB major version in db.h configure:20331: result: none configure:20334: error: Unknown Berkeley DB major version in db.h

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com 06 Jul '15

06 Jul '15

This is a cryptographically signed message in MIME format. --------------ms000206000000020208060300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kartik Subbarao wrote: > You mention that "pwdFailureTime is also used as a failure lockout coun= ter". I > don't see how that conflicts with what I am requesting. I'm only asking= for > /excess/ pwdFailureTime values that are above the pwdMaxFailure count t= o be > purged. Oh, I see. Indeed I did not fully understand your original message. > For example, if pwdMaxFailure is 3, and pwdFailureTime has the > following values: >=20 > pwdFailureTime: 20150702184821Z > pwdFailureTime: 20150702185821Z > pwdFailureTime: 20150702190822Z > pwdFailureTime: 20150702191007Z > pwdFailureTime: 20150702191012Z >=20 > What I'm requesting is that the /oldest/ two values be deleted from thi= s set: Hmm, still have some doubts: If you want to raise the failure count limit= later you would automatically unlock some accounts you don't want to unlo= ck at this particular point in time. Ciao, Michael. --------------ms000206000000020208060300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwNjE2MjUwMFowLwYJKoZIhvcNAQkEMSIE IH7+cZbIVOCGL55ZjKKaUB/HHprnj2PhEJuxySRq8xP/MGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQAYG+byNJRgIHP9toZH8tn2UbQgnS24FVS+UMsGsFfpaITB5HECe9wH hJnCbzGUBE7YIXOKXCqSPbv5O+p9oj8IfP9Go80R8Gemrx3/MdnaxGGBDkvBLLlyrRhvVfTm a0MKEuwXrTMeAmf33hmAeMtJxdYJj8ibRO4HWf1rsivzIjnvyajdVvCjEWKhHk8l5u6D3icw 7ufZtt6B49R3gaYaE072rp+5r9iENwgwF60RacNGTMfjtSlNCN3WHEbIq9Eys1EZ5BKaBc44 VcYKDP1zoqe4QXoxxJ85uFySM6AScLAod0el8Z9GXNwe7m795l6lIgeY0dye7HBTWMJUteTD AAAAAAAA --------------ms000206000000020208060300--

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