openldap-bugs

openldap-bugs@openldap.org

1 participants
20998 discussions

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 10 Nov '06

10 Nov '06

michael(a)stroeder.com wrote: > It seems that slapd stops without configuration error message if unknown > attribute types are set for parameter unique_attributes (slapo-unique). It would > be nice if a descriptive message is displayed (like in other cases). > I think this occurs if debug is set to "config" or "-1". However, it would be more appropriate to log configuration errors that result in failures at "any", so that whatever logging is set they show up. For this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that they show up when caught by tools with default logging (e.g. slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. I'd vote for the latter. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4743) ldapsearch manpage Project reference
by quanah＠stanford.edu 10 Nov '06

10 Nov '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28/2.3.29 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The ldapsearch(1) man page was sync'd for the 2.3.28 release, and inadverdently included a reference to the "Projects" file, which is a HEAD specific bit.

1 0

(ITS#4742) parameter unique_attributes and unknown attribute types
by michael＠stroeder.com 10 Nov '06

10 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.25.247) HI! It seems that slapd stops without configuration error message if unknown attribute types are set for parameter unique_attributes (slapo-unique). It would be nice if a descriptive message is displayed (like in other cases). Ciao, Michael.

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 10 Nov '06

10 Nov '06

Eric Covener wrote: > On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: >> covener(a)gmail.com wrote: >> > FWIW, Another SDK I'm working with exposes a once-per-process SSL >> > initialization method, that would amount to ldap_pvt_tls_init(); >> >> A fix for this is in HEAD, please test. > > Now working for me on HEAD: > ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); > ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); > ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); > > ld1 = ldap_init(h,p); > ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); > ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); > ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); > > ld2 = ldap_init(h,p); > > and connections to ld1 and ld2 send the right client cert over the > wire. Hope this is a resonable API usage -- Much appreciated! > Thanks for the confirmation. The is_server flag only needs to be set non-zero if you are going to be accepting incoming TLS sessions with that context. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 10 Nov '06

10 Nov '06

On 11/9/06, Howard Chu <hyc(a)symas.com> wrote: > covener(a)gmail.com wrote: > > FWIW, Another SDK I'm working with exposes a once-per-process SSL > > initialization method, that would amount to ldap_pvt_tls_init(); > > A fix for this is in HEAD, please test. Now working for me on HEAD: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, /CA.pem); ldap_set_option(NULL, LDAP_OPT_X_TLS_CERTFILE, "/cert1.pem"); ldap_set_option(NULL, LDAP_OPT_X_TLS_KEYTFILE, "/cert1.key"); ld1 = ldap_init(h,p); ldap_set_option(ld1, LDAP_OPT_X_TLS_CERTFILE, "/cert2.pem"); ldap_set_option(ld1, LDAP_OPT_X_TLS_KEYTFILE, "/cert2.key"); ldap_set_option(ld1, LDAP_OPT_X_NEW_CTX, &(is_server)); ld2 = ldap_init(h,p); and connections to ld1 and ld2 send the right client cert over the wire. Hope this is a resonable API usage -- Much appreciated! -- Eric Covener covener(a)gmail.com

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by hyc＠symas.com 09 Nov '06

09 Nov '06

covener(a)gmail.com wrote: > FWIW, Another SDK I'm working with exposes a once-per-process SSL > initialization method, that would amount to ldap_pvt_tls_init(); A fix for this is in HEAD, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 09 Nov '06

09 Nov '06

FWIW, Another SDK I'm working with exposes a once-per-process SSL initialization method, that would amount to ldap_pvt_tls_init();

1 0

(ITS#4739)
by hardimankevin＠yahoo.com 09 Nov '06

09 Nov '06

--0-1558012606-1163097706=:73509 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies for the breach of etiqette. Will change the backend.=0A=0A -k= ph=0A=0A=0A=0A=0A=0A=0A =0A________________________________________________= ____________________________________=0ADo you Yahoo!?=0AEveryone is raving = about the all-new Yahoo! Mail beta.=0Ahttp://new.mail.yahoo.com --0-1558012606-1163097706=:73509 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable <html><head><style type=3D"text/css"></style></he= ad><body><div style=3D"font-family:arial, helvetica, sans-serif;font-size:1= 0pt"><div>Apologies for the breach of etiqette.  Will change the backe= nd.<br><br>    -kph<br><br><br></div></div><br>=0A=0A=0A<hr = size=3D1>Everyone is raving about <a href=3D"http://us.rd.yahoo.com/evt=3D4= 2297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail= beta.</a></body></html> --0-1558012606-1163097706=:73509--

1 0

Re: (ITS#4741) ppolicy.c improperly discards return value of check_password() function
by hyc＠symas.com 09 Nov '06

09 Nov '06

lsherida(a)nccs.nasa.gov wrote: > Full_Name: Lee Sheridan > Version: 2.3.27 > OS: Debian GNU/Linux (etch) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.168.13.7) > > > In servers/slapd/overlays/ppolicy.c, check_password_quality function, at > line 530, the value of the 'ok' variable is discarded by unconditionally > assigning it the value LDAP_SUCCESS. > > The variable is the return code of the user-defined check_password() function, > which is assigned at line 522. The next if-then-else block is checking to > see if the module reported an error, at which point 'ok' would be assigned > LDAP_OTHER regardless of what check_password() returned. A superfluous else > block appears after this check, assigning 'ok' to LDAP_SUCCESS. > > It works fine for me if I remove the else block. > > Thanks, A fix has been committed to CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

[Fwd: Re: (ITS#4739) Server crashes every time alias is dereferenced]
by hyc＠symas.com 09 Nov '06

09 Nov '06

This is a multi-part message in MIME format. --------------080602030800020000070003 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is the info Kevin sent before. aliases are known to work incorrectly in back-ldbm. back-ldbm has been deprecated since OpenLDAP 2.2 and has been deleted from the source tree for OpenLDAP 2.4. As such, I don't see us taking any action on this bug report. Use back-bdb or back-hdb instead. -------- Original Message -------- Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced Date: Wed, 8 Nov 2006 22:09:51 -0800 (PST) From: Kevin Hardiman <hardimankevin(a)yahoo.com> To: Howard Chu <hyc(a)symas.com> Howard, To answer your initial questions: 1. The aliased entry does exist 2. The backined is ldbm 3. Attached is a sanitized slapd.conf 4. Attached is a sanitized ldif export Here's the output from running slapd (sanitized for sensitive information) without forking (-d 1): > >> dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com> <<< dnPrettyNormal: <ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com>, <ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: => ldbm_back_search dn2entry_r: dn: "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" => dn2id( "ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) ====> cache_find_entry_ndn2id("ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com"): 16378 (1 tries) <= dn2id 16378 (in cache) => id2entry_r( 16378 ) ====> cache_find_entry_id( 16378 ) "ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16378 ) 0x82d2068 (cache) search_candidates: base="ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" s=2 d=3 => filter_candidates => list_candidates 0xa0 => filter_candidates => dn2idl( "@ou=users,ou=example,ou=smb,ou=core services,dc=example,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= filter_candidates 2 => filter_candidates => list_candidates 0xa1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 1 candidates <= equality_candidates 1 <= filter_candidates 1 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 idl_free: called with NULL pointer => filter_candidates => list_candidates 0xa0 => filter_candidates => equality_candidates => ldbm_cache_open( "objectClass.dbb", 73, 600 ) <= ldbm_cache_open (cache 3) => key_read <= index_read 4 candidates <= equality_candidates 4 <= filter_candidates 4 => filter_candidates => equality_candidates => ldbm_cache_open( "uid.dbb", 73, 600 ) <= ldbm_cache_open (cache 4) => key_read <= index_read 0 candidates <= equality_candidates NULL <= equality_candidates 0 <= filter_candidates 0 <= list_candidates NULL <= filter_candidates 0 idl_free: called with NULL pointer <= list_candidates 1 <= filter_candidates 1 <= list_candidates 1 <= filter_candidates 1 ====> cache_return_entry_r( 16378 ): returned (0) => id2entry_r( 16400 ) ====> cache_find_entry_id( 16400 ) "uid=test,ou=Users,ou=example,ou=smb,ou=Core Services,dc=example,dc=com" (found) (1 tries) <= id2entry_r( 16400 ) 0x82d5580 (cache) dn2entry_r: dn: "ÿÿÐuhH_øP" => dn2id( "ÿÿÐuhH_øP" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (cache 0) <= dn2id NOID slapd: dn.c:1148: dnParent: Assertion `( ( ( ( (p[ 0 ]) >= 'a' && (p[ 0 ]) <= 'z' ) || ( (p[ 0 ]) >= 'A' && (p[ 0 ]) <= 'Z' ) ) ) || ( ( (p[ 0 ]) >= '0' && (p[ 0 ]) <= '9' ) ) )' failed. Aborted Let me know if you need anything else. Regards, Kevin Hardiman ----- Original Message ---- From: Howard Chu <hyc(a)symas.com> To: hardimankevin(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Wednesday, November 8, 2006 9:45:27 PM Subject: Re: (ITS#4739) Server crashes every time alias is dereferenced hardimankevin(a)yahoo.com wrote: > Full_Name: Kevin Hardiman > Version: 2.3.27 > OS: Linux (Mandriva 2007) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.90.130.182) > > > Using the very simple alias below, OpenLDAP will crash every time it is > dereferenced: > > dn: uid=test,ou=Users,ou=bladiant,ou=smb,ou=Core Services,dc=example,dc=com > objectClass: alias > objectclass: extensibleObject > uid: test > aliasedObjectName: uid=test,ou=Users,dc=example,dc=com > > This error has been experience with OpenLDAP releases 2.3.6 and 2.3.27, both in > the form of provided Mandriva packages. I also have seen a number of references > to this error in previous releases, with no explicit fix. Please advise. Well, considering that no one has reported any such problem during the whole time releases 2.3.6-2.3.27 were published, it's no surprise that there has been no fix yet. There's not enough information here to reproduce the bug. What backend are you using, what other entries are in the database? In particular, does "uid=test,ou=Users,dc=example,dc=com" exist? You should provide a sample slapd.conf and minimal LDIF needed to reproduce the error. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ ------------------------------------------------------------------------ Sponsored Link $200,000 mortgage for $660/mo - 30/15 yr fixed, reduce debt, home equity - Click now for info <http://www.ratemarketplace.com/forms/form.jsp?ADEL=Os4fVJ19lSwzAOc/zMz/CYLq…> -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ --------------080602030800020000070003 Content-Type: application/octet-stream; name="slapd.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd.conf" aW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRl CS91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkvdXNy L3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jb3JiYS5zY2hlbWEgCmluY2x1ZGUJL3Vzci9zaGFy ZS9vcGVubGRhcC9zY2hlbWEvaW5ldG9yZ3BlcnNvbi5zY2hlbWEKaW5jbHVkZQkvdXNyL3No YXJlL29wZW5sZGFwL3NjaGVtYS9qYXZhLnNjaGVtYSAKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9rcmI1LWtkYy5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5s ZGFwL3NjaGVtYS9rZXJiZXJvc29iamVjdC5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29w ZW5sZGFwL3NjaGVtYS9taXNjLnNjaGVtYQppbmNsdWRlCS91c3Ivc2hhcmUvb3BlbmxkYXAv c2NoZW1hL25pcy5zY2hlbWEKaW5jbHVkZQkvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9v cGVubGRhcC5zY2hlbWEgCmluY2x1ZGUgL3Vzci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvYXV0 b2ZzLnNjaGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL3NhbWJhLnNj aGVtYQppbmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2tvbGFiLnNjaGVtYQpp bmNsdWRlIC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2V2b2x1dGlvbnBlcnNvbi5zY2hl bWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9jYWxlbmRhci5zY2hlbWEK aW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3NjaGVtYS9zdWRvLnNjaGVtYQppbmNsdWRl IC91c3Ivc2hhcmUvb3BlbmxkYXAvc2NoZW1hL2Ruc3pvbmUuc2NoZW1hCmluY2x1ZGUgL3Vz ci9zaGFyZS9vcGVubGRhcC9zY2hlbWEvZGhjcC5zY2hlbWEKaW5jbHVkZQkvZXRjL29wZW5s ZGFwL3NjaGVtYS9sb2NhbC5zY2hlbWEKaW5jbHVkZSAvdXNyL3NoYXJlL29wZW5sZGFwL3Nj aGVtYS9tb3ppbGxhQWJQZXJzb25BbHBoYS5zY2hlbWEKaW5jbHVkZSAJL2V0Yy9vcGVubGRh cC9zbGFwZC5hY2Nlc3MuY29uZgoKYWNjZXNzIHRvIGRuLnN1YnRyZWU9ImRjPWV4YW1wbGUs ZGM9Y29tIgogICAgICAgIGJ5IGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4 YW1wbGUsZGM9Y29tIgogICAgICAgIGJ5IHVzZXJzIHJlYWQKICAgICAgICBieSBhbm9ueW1v dXMgcmVhZAoKbGltaXRzIGdyb3VwPSJjbj1SZXBsaWNhdG9yLG91PUdyb3VwLGRjPWV4YW1w bGUsZGM9Y29tIgogc2l6ZT11bmxpbWl0ZWQKIHRpbWU9dW5saW1pdGVkCnBpZGZpbGUJCS92 YXIvcnVuL2xkYXAvc2xhcGQucGlkCmFyZ3NmaWxlCS92YXIvcnVuL2xkYXAvc2xhcGQuYXJn cwptb2R1bGVwYXRoCS91c3IvbGliL29wZW5sZGFwClRMU1JhbmRGaWxlICAgICAgICAgICAg L2Rldi9yYW5kb20KVExTQ2lwaGVyU3VpdGUgICAgICAgICBISUdIOk1FRElVTTorU1NMdjIK VExTQ2VydGlmaWNhdGVGaWxlICAgICAgL2V0Yy9zc2wvb3BlbmxkYXAvbGRhcGNlcnQucGVt ClRMU0NlcnRpZmljYXRlS2V5RmlsZSAgIC9ldGMvc3NsL29wZW5sZGFwL2xkYXBrZXkucGVt ClRMU0NBQ2VydGlmaWNhdGVQYXRoICAgL2V0Yy9zc2wvb3BlbmxkYXAvClRMU0NBQ2VydGlm aWNhdGVGaWxlICAgIC9ldGMvc3NsL29wZW5sZGFwL2NhY2VydC5wZW0KVExTVmVyaWZ5Q2xp ZW50IHRyeSAjIChbbmV2ZXJdfGFsbG93fHRyeXxkZW1hbmQpCmxvZ2xldmVsIDI2OAphbGxv dyBiaW5kX3YyCnNhc2wtc2VjcHJvcHMgbm9uZQpkYXRhYmFzZQlsZGJtCnN1ZmZpeAkJImRj PWJsYWRpYW50LGRjPWNvbSIKcm9vdGRuCQkiY249S2V2aW4gSGFyZGltYW4sb3U9UGVvcGxl LGRjPWV4YW1wbGUsZGM9Y29tIgpsYXN0bW9kCQlvbgpkaXJlY3RvcnkJL3Zhci9saWIvbGRh cApjaGVja3BvaW50IDI1NiA1CmluZGV4CW9iamVjdENsYXNzLHVpZCx1aWROdW1iZXIsZ2lk TnVtYmVyLG1lbWJlcnVpZAllcQppbmRleAljbixtYWlsLHN1cm5hbWUsZ2l2ZW5uYW1lCQll cSxzdWJpbml0aWFsCiAK --------------080602030800020000070003 Content-Type: application/octet-stream; name="minimal_export.ldif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="minimal_export.ldif" ZG46IG91PVVzZXJzLCBkYz1leGFtcGxlLGRjPWNvbQpvdTogVXNlcnMKb2JqZWN0Q2xhc3M6 IG9yZ2FuaXphdGlvbmFsVW5pdAoKZG46IHVpZD10ZXN0LCBvdT1Vc2VycywgZGM9ZXhhbXBs ZSxkYz1jb20Kc2FtYmFQcmltYXJ5R3JvdXBTSUQ6IFhYWFgKc2FtYmFMTVBhc3N3b3JkOiBY WFhYCmRpc3BsYXlOYW1lOiBLZXZpbiBIYXJkaW1hbgpvYmplY3RDbGFzczogdG9wCm9iamVj dENsYXNzOiBpbmV0T3JnUGVyc29uCm9iamVjdENsYXNzOiBwb3NpeEFjY291bnQKb2JqZWN0 Q2xhc3M6IHNoYWRvd0FjY291bnQKb2JqZWN0Q2xhc3M6IHNhbWJhU2FtQWNjb3VudAp1c2Vy UGFzc3dvcmQ6OiBYWFhYCnNhbWJhTG9nb25UaW1lOiAwCnVpZE51bWJlcjogNTAwCnVpZDog dGVzdApjbjogdGVzdApzYW1iYUxvZ29mZlRpbWU6IDIxNDc0ODM2NDcKc2FtYmFQd2RMYXN0 U2V0OiAxMTYxOTIzMzcwCmxvZ2luU2hlbGw6IC9iaW4vYmFzaApzYW1iYUFjY3RGbGFnczog W1VdCmdpZE51bWJlcjogMTAwCnNhbWJhUHdkTXVzdENoYW5nZTogMTE2NTgxMTM3MApzYW1i YVNJRDogWFhYCnNhbWJhUHdkQ2FuQ2hhbmdlOiAwCnNhbWJhTlRQYXNzd29yZDogWFhYCmdl Y29zOiBLZXZpbiBIYXJkaW1hbgpkZXNjcmlwdGlvbjogS2V2aW4gSGFyZGltYW4KaG9tZURp cmVjdG9yeTogL2hvbWUvdGVzdApzYW1iYUtpY2tvZmZUaW1lOiAyMTQ3NDgzNjQ3CnNuOiBI YXJkaW1hbgoKZG46IG91PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBD b3JlIFNlcnZpY2VzCm9iamVjdENsYXNzOiB0b3AKb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlv bmFsVW5pdAoKZG46IG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhhbXBsZSxkYz1j b20Kb3U6IHNtYgpvYmplY3RDbGFzczogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25h bFVuaXQKCmRuOiBvdT1leGFtcGxlLG91PXNtYiwgb3U9Q29yZSBTZXJ2aWNlcywgZGM9ZXhh bXBsZSxkYz1jb20Kb3U6IGV4YW1wbGUKb2JqZWN0Q2xhc3M6IHRvcApvYmplY3RDbGFzczog b3JnYW5pemF0aW9uYWxVbml0Cgpkbjogb3U9VXNlcnMsb3U9ZXhhbXBsZSxvdT1zbWIsIG91 PUNvcmUgU2VydmljZXMsIGRjPWV4YW1wbGUsZGM9Y29tCm91OiBVc2VycwpvYmplY3RDbGFz czogdG9wCm9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKCmRuOiB1aWQ9dGVzdCxv dT1Vc2VycyxvdT1leGFtcGxlLG91PXNtYixvdT1Db3JlIFNlcnZpY2VzLGRjPWV4YW1wbGUs ZGM9Y29tCm9iamVjdENsYXNzOiBhbGlhcwpvYmplY3RjbGFzczogZXh0ZW5zaWJsZU9iamVj dAp1aWQ6IHRlc3QKYWxpYXNlZE9iamVjdE5hbWU6IHVpZD10ZXN0LG91PVVzZXJzLGRjPWV4 YW1wbGUsZGM9Y29tCg== --------------080602030800020000070003--

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