openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

(ITS#7393) slapd crash when changing an attribute name to an existing name
by ddick＠cpan.org 17 Sep '12

17 Sep '12

Full_Name: David Dick Version: 2.4.26 OS: Fedora 16 URL: Submission from: (NULL) (124.148.129.18) When changing the NAME of an attribute to the name of an existing attribute, the slapd process crashes. The following set of statements in ldif format will crash the server; The cn={12} was chosen as the next available schema index and may need to be adjusted appropriately. dn: cn={12}crashme,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: {12}crashme olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'SmtpHost' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn={12}crashme,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'MailHost' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1 0

Re: (ITS#7388) [PATCH] MozNSS: ignore certdb 'sql:' prefix when checking directory existence
by jvcelak＠redhat.com 16 Sep '12

16 Sep '12

Hello Howard, > The patch looks syntactically correct. But SQL, seriously? As if TLS > handshakes weren't slow enough already, you want to slow them down > even > further by looking up certs in an SQL database? this is nothing new. Mozilla NSS supports SQL backend (SQLite) for storing certificates since 3.12 (== Firefox 3) I think. The reason, why the new format was introduced is mainly because of problems with accesing the database from multiple processes. It is described on the following page in a great detail: https://wiki.mozilla.org/NSS_Shared_DB I can't tell anything about the performance because I haven't tried. > Aside from questioning the wisdom of such an inefficient approach, > there are > other philosophical problems with this patch. It seems to be just the > latest > in a continuing stream of one-off patches. Are we going to get yet > another > special case patch from you guys when some other new certDB type > comes along? One Fedora user e-mailed me recently and wanted my help with setting the OpenLDAP server to use the database in "new" sql format. This patch is the result. I do not think that any other backend except the legacy and this one is supported. Otherwise, I would write the patch more generally. I will check with MozNSS people and let you know. > This approach is unmaintainable and does nothing to inspire > confidence in the > quality of thinking going into this code. > > You're working on a security library. We expect a lot better thought > to go > into these things. I fully understand and expect that you will have some feedback on our patches - which is happening right now. MozNSS crypto backend works quite fine, but there are still some problems in certain corner situations. The backend is not as mature as OpenSSL one. I'm really trying to fix them all and to make OpenLDAP a better piece of software. Jan

1 0

Re: (ITS#7392) ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by daniel＠pluta.biz 16 Sep '12

16 Sep '12

Hi, applying the patch linked below both previously mentioned operations produce the following log Operation 1: log level 128 ========================== 505573f8 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 505573f8 => dn: [1] dc=example,dc=org 505573f8 => dn: [2] dc=example,dc=org 505573f8 => acl_get: [2] matched 505573f8 => acl_get: [2] attr owner 505573f8 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 505573f8 => acl_mask: to value by "uid=user,dc=example,dc=org", (=0) 505573f8 <= check a_dn_at: owner 505573f8 <= acl_mask: [1] applying read(=rscxd) (stop) 505573f8 <= acl_mask: [1] mask: read(=rscxd) 505573f8 => slap_access_allowed: delete access denied by read(=rscxd) 505573f8 => access_allowed: no more rules 505573f8 => access_allowed: result not in cache (owner) Operation 2: log level 128 ========================== 505573f8 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 505573f8 => dn: [1] dc=example,dc=org 505573f8 => dn: [2] dc=example,dc=org 505573f8 => acl_get: [2] matched 505573f8 => acl_get: [2] attr owner 505573f8 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 505573f8 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 505573f8 => acl_mask: to self, attr "owner" 505573f8 <= check a_dn_at: owner 505573f8 <= acl_mask: [1] applying read(=rscxd) (stop) 505573f8 <= acl_mask: [1] mask: read(=rscxd) 505573f8 => slap_access_allowed: delete access denied by read(=rscxd) 505573f8 => access_allowed: no more rules ftp://ftp.openldap.org/incoming/Daniel-Pluta-120916.patch DISCLAIMER: It's not heavyly tested. I don't know whether the patch causes negative sideeffects elsewhere.

1 0

(ITS#7392) ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by daniel＠pluta.biz 15 Sep '12

15 Sep '12

Full_Name: Daniel Pluta Version: Linux OS: OPENLDAP_REL_ENG_2_4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.49.115) Hi, given this (simplyfied and thus quite strange looking) sample acl statement: access to dn.one="dc=example,dc=org" attrs=@groupOfNames by dnattr=owner selfread by users write the first by clause ("by dnattr=owner selfread") is only honored in case of an access "to value", like for example: #Operation 1 (log see below): dn: cn=group,dc=example,dc=org changetype: modify delete: owner owner: uid=user,dc=example,dc=org - but is skipped in case of an access "to all values", like for example: #Operation 2 (log see below): dn: cn=group,dc=example,dc=org changetype: modify delete: owner - In case (hopefully) this is not the intended behavior. The following "comment-patch" could be the place to start further investigations. Thanks a lot. diff --git a/servers/slapd/acl.c b/servers/slapd/acl.c index 4b72342..89cb9ae 100644 --- a/servers/slapd/acl.c +++ b/servers/slapd/acl.c @@ -1170,7 +1170,14 @@ slap_acl_mask( !is_at_syntax( desc->ad_type, SLAPD_NAMEUID_SYNTAX )) continue; /* check if the target is an attribute. */ - if ( val == NULL ) continue; + if ( val == NULL ) { + /* check all values whether a_dn.a_self is contained */ + + /* if a_dn.a_self is contained: implicitly set val to a_dn.a_self */ + + /* else: continue */ + continue; + } /* a DN must be present */ if ( BER_BVISEMPTY( &op->o_ndn ) ) { Operation 1: log level 128 ========================== 5054ed13 => access_allowed: result not in cache (owner) 5054ed13 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 5054ed13 => dn: [1] dc=example,dc=org 5054ed13 => dn: [2] dc=example,dc=org 5054ed13 => acl_get: [2] matched 5054ed13 => acl_get: [2] attr owner 5054ed13 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 5054ed13 => acl_mask: to value by "uid=user,dc=example,dc=org", (=0) 5054ed13 <= check a_dn_at: owner 5054ed13 <= acl_mask: [1] applying read(=rscxd) (stop) 5054ed13 <= acl_mask: [1] mask: read(=rscxd) 5054ed13 => slap_access_allowed: delete access denied by read(=rscxd) 5054ed13 => access_allowed: no more rules Operation 2: log level 128 ========================== 5054ed29 => access_allowed: result not in cache (owner) 5054ed29 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 5054ed29 => dn: [1] dc=example,dc=org 5054ed29 => dn: [2] dc=example,dc=org 5054ed29 => acl_get: [2] matched 5054ed29 => acl_get: [2] attr owner 5054ed29 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 5054ed29 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5054ed29 <= check a_dn_pat: users 5054ed29 <= acl_mask: [2] applying write(=wrscxd) (stop) 5054ed29 <= acl_mask: [2] mask: write(=wrscxd) 5054ed29 => slap_access_allowed: delete access granted by write(=wrscxd) 5054ed29 => access_allowed: delete access granted by write(=wrscxd) 5054ed29 acl: internal mod entryCSN: modify access granted 5054ed29 acl: internal mod modifiersName: modify access granted 5054ed29 acl: internal mod modifyTimestamp: modify access granted slapd.conf: =========== include /tmp/example/core.schema include /tmp/example/cosine.schema include /tmp/example/sociopath.schema pidfile /tmp/example/run/slapd.pid argsfile /tmp/example/run/slapd.args access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by * read database mdb suffix "dc=example,dc=org" rootdn "cn=Manager,dc=example,dc=org" rootpw secret directory /tmp/example/data index objectClass eq add_content_acl on access to dn.base="dc=example,dc=org" attrs=children by users write #simplyfied, thus probably strange looking, but nevertheless valid: access to dn.one="dc=example,dc=org" attrs=@groupOfNames by dnattr=owner selfread by users write access to dn.one="dc=example,dc=org" by self read by users read by anonymous auth

1 0

Re: (ITS#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Howard Chu wrote: > Thanks, fixed in master. Seems to be fixed in RE24 f5231cc6175be6c591345b6c4c069ba2859a1f0a Thanks. Ciao, Michael.

1 0

Re: (ITS#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by hyc＠symas.com 14 Sep '12

14 Sep '12

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: RE24 42baa43cb92bc52081d24d925a584dd430437d75 > URL: > Submission from: (NULL) (79.227.150.68) > > > With recent fixes for mdb in RE24 42baa43cb92bc52081d24d925a584dd430437d75 > slapcat does not work anymore while slapd can access the DB quite well: Thanks, fixed in master. > > 50537559 mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore > from backup! > 50537559 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open > failed! (13) > slap_startup failed > /home/michael/backups/openldap2.4-stroeder.de-accesslog-2012-09-14T20:20:09.ldif.bz2: > ok > 50537559 mdb_db_open: database "dc=stroeder,dc=de" cannot be opened, err 13. > Restore from backup! > 50537559 backend_startup_one (type=mdb, suffix="dc=stroeder,dc=de"): bi_db_open > failed! (13) > slap_startup failed > /home/michael/backups/openldap2.4-stroeder.de-daten-2012-09-14T20:20:09.ldif.bz2: > ok > > -- -- 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#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Full_Name: Version: OS: RE24 42baa43cb92bc52081d24d925a584dd430437d75 URL: Submission from: (NULL) (79.227.150.68) With recent fixes for mdb in RE24 42baa43cb92bc52081d24d925a584dd430437d75 slapcat does not work anymore while slapd can access the DB quite well: 50537559 mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup! 50537559 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open failed! (13) slap_startup failed /home/michael/backups/openldap2.4-stroeder.de-accesslog-2012-09-14T20:20:09.ldif.bz2: ok 50537559 mdb_db_open: database "dc=stroeder,dc=de" cannot be opened, err 13. Restore from backup! 50537559 backend_startup_one (type=mdb, suffix="dc=stroeder,dc=de"): bi_db_open failed! (13) slap_startup failed /home/michael/backups/openldap2.4-stroeder.de-daten-2012-09-14T20:20:09.ldif.bz2: ok

1 0

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

hyc(a)symas.com wrote: > Fixed in git master. I've retested with git master and it works. Thanks! Ciao, Michael.

1 0

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by hyc＠symas.com 14 Sep '12

14 Sep '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> This is a multi-part message in MIME format. >>> --------------030803020000090707060805 >>> Content-Type: text/plain; charset=UTF-8 >>> Content-Transfer-Encoding: 7bit >>> >>> See slapd.conf attached. >> >> What is init.schema? Is it required to reproduce the bug? > > Not required. Just a bunch of include foo.schema. > > Ciao, Michael. > Fixed in git master. -- -- 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#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

This is a cryptographically signed message in MIME format. --------------ms000502010807010504000507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> This is a multi-part message in MIME format. >> --------------030803020000090707060805 >> Content-Type: text/plain; charset=3DUTF-8 >> Content-Transfer-Encoding: 7bit >> >> See slapd.conf attached. >=20 > What is init.schema? Is it required to reproduce the bug? Not required. Just a bunch of include foo.schema. Ciao, Michael. --------------ms000502010807010504000507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTE0MTYyNDU2WjAjBgkq hkiG9w0BCQQxFgQUYmt9gfUW0xkqivQP/OBG2f/WQ8AwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAYMuUMe9Ve9zSu2WRZaxt/AxcTjcq25GgkBDUh1pBU8+iB4P8mdDI3DGXmBh4jXDicUbD GSx1USI2fcvOmBMC30e4QTWcs018i38yYsYDiTUlvDlT7dxWkshrQLHDjpmG2Dpy02hz6KRJ dRYlNfvmtVsRQtgTMm9XaguD6BBzioxBsakJDPxtRF1w87NdCSjk2YKKwcPYjZNKjX955hBc CPKeK+fAxNURLkucf28/8Rx2bYKtAQmon6g9y/6VLaRuxUBLD5lunqCNYWiG0L3RA1HAeffr p9Pjcwa0JU7r/2UqxpdMh1lfkQLvqB4fbA9ej+Da6ikylHNRPyvMhJpJtwAAAAAAAA== --------------ms000502010807010504000507--

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