openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by quanah＠symas.com 23 Feb '18

23 Feb '18

--On Friday, February 23, 2018 5:07 PM +0000 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: HEAD >> OS: N/A >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (47.208.148.239) >> >> >> When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL >> has been built with deprecated API's disabled, the build will fail. >> This is because RSA_F4 is deprecated in 1.0.2. In master, this is >> around line 1367: >> >> # if OPENSSL_VERSION_NUMBER < 0x10100000 >> static RSA * >> tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) > >> This function needs to check < 1.0.2 rather than < 1.1 > > That would only be true if the RSA callback is not needed at all in > 1.0.2. Is that true? Not sure. Exact error is in RE24 is: tls_o.c:1184:25: error: 'RSA_F4' undeclared (first use in this function) if ( BN_set_word( bn, RSA_F4 )) { so it dies before we get to the RSA_generate_key_ex function itself. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by hyc＠symas.com 23 Feb '18

23 Feb '18

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL has been > built with deprecated API's disabled, the build will fail. This is because > RSA_F4 is deprecated in 1.0.2. In master, this is around line 1367: > > #if OPENSSL_VERSION_NUMBER < 0x10100000 > static RSA * > tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) > This function needs to check < 1.0.2 rather than < 1.1 That would only be true if the RSA callback is not needed at all in 1.0.2. Is that true? -- -- 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#8809) tls_o failure when linking to OpenSSL 1.0.2 with "no-deprecated" compile flag
by quanah＠openldap.org 23 Feb '18

23 Feb '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When attempting to link OpenLDAP to OpenSSL 1.0.2 series, where OpenSSL has been built with deprecated API's disabled, the build will fail. This is because RSA_F4 is deprecated in 1.0.2. In master, this is around line 1367: #if OPENSSL_VERSION_NUMBER < 0x10100000 static RSA * tlso_tmp_rsa_cb( SSL *ssl, int is_export, int key_length ) { RSA *tmp_rsa; /* FIXME: Pregenerate the key on startup */ /* FIXME: Who frees the key? */ #if OPENSSL_VERSION_NUMBER >= 0x00908000 BIGNUM *bn = BN_new(); tmp_rsa = NULL; if ( bn ) { if ( BN_set_word( bn, RSA_F4 )) { tmp_rsa = RSA_new(); if ( tmp_rsa && !RSA_generate_key_ex( tmp_rsa, key_length, bn, NULL )) { RSA_free( tmp_rsa ); tmp_rsa = NULL; } } BN_free( bn ); } #else tmp_rsa = RSA_generate_key( key_length, RSA_F4, NULL, NULL ); #endif if ( !tmp_rsa ) { Debug( LDAP_DEBUG_ANY, "TLS: Failed to generate temporary %d-bit %s RSA key\n", key_length, is_export ? "export" : "domestic", 0 ); } return tmp_rsa; } #endif /* OPENSSL_VERSION_NUMBER < 1.1 */ This function needs to check < 1.0.2 rather than < 1.1

1 0

Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by hyc＠symas.com 15 Feb '18

15 Feb '18

cheimes(a)redhat.com wrote: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP > Content-Type: multipart/mixed; boundary="ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd"; > protected-headers="v1" > From: Christian Heimes <cheimes(a)redhat.com> > To: Howard Chu <hyc(a)symas.com>, openldap-its(a)OpenLDAP.org > Message-ID: <1ad5d71c-c2c2-701e-1550-5296c850a51e(a)redhat.com> > Subject: Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong > References: <E1emLjU-0005uv-8G(a)gauss.openldap.net> > <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> > In-Reply-To: <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> > > --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > On 2018-02-15 17:04, Howard Chu wrote: >> I see no disagreement between the code and the documentation. Please >> elaborate, otherwise this ITS will be closed. > > For a non-native speaker, the documentation sounds a bit like > ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0) does not create a new > context at all because the input value is zero. Could you please mention > that a zero value creates a client context? "This option creates a context. If you specify a 1, it will create a context for a server." Nothing in these statements implies that it will *not* create a context. Closing this ITS. -- -- 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#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by cheimes＠redhat.com 15 Feb '18

15 Feb '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP Content-Type: multipart/mixed; boundary="ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd"; protected-headers="v1" From: Christian Heimes <cheimes(a)redhat.com> To: Howard Chu <hyc(a)symas.com>, openldap-its(a)OpenLDAP.org Message-ID: <1ad5d71c-c2c2-701e-1550-5296c850a51e(a)redhat.com> Subject: Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong References: <E1emLjU-0005uv-8G(a)gauss.openldap.net> <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> In-Reply-To: <9e35c40f-d567-5dec-dd5d-085dcd356483(a)symas.com> --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-02-15 17:04, Howard Chu wrote: > I see no disagreement between the code and the documentation. Please > elaborate, otherwise this ITS will be closed. For a non-native speaker, the documentation sounds a bit like ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0) does not create a new context at all because the input value is zero. Could you please mention that a zero value creates a client context? --=20 Christian Heimes Senior Software Engineer, Identity Management and Platform Security Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander --ImAEehvUF6AyAI2LgcI3vl7LvbpVlLmbd-- --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEL7+ElqIWjf0BBClLhmhSSSEttokFAlqFtLAACgkQhmhSSSEt ton6FggAqOSMIaWDSrVLYVQPxhqAQh+HDbinIaxgLPZarYxr0ijth8wPbpdt0f1s Bgq21a71Qkrrr9joDhb6T3I7ZOs85wsq8mFlHAqciVV2qJGCOFDYd7SOveAyyY6/ PgETKxQ9/S/ei+8NKiRhc0UP2wAvUF8pus7TyJDMao8/EumButO8R8MJWydBOdkh /5kUuROlo1B9owujmNY9V7tIKUU5to6zj1r05gJXrznP+ex+ZkoJz6Us+PedueRe uF5/jAibFnLIpk0WRN+DdTl1PqZnXVGHfBaHsVbpH5Wff+yzxgUNwo4zmQB6sCuA w+82yYr0Lbh243efKYPC+ivRjfs4kg== =A94C -----END PGP SIGNATURE----- --xtLU7S4g0jUK8GMHh0QtLLEN50A6OirhP--

1 0

Re: (ITS#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by hyc＠symas.com 15 Feb '18

15 Feb '18

cheimes(a)redhat.com wrote: > Full_Name: Christian Heimes > Version: 2.4.45 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:16b8:607e:f300:6312:6da:8e63:dfa2) > > > The documentation for ldap_set_option LDAP_OPT_X_TLS_NEWCTX is wrong or at least > misleading. The man page https://linux.die.net/man/3/ldap_set_option describes > the option as: > >> Instructs the library to create a new TLS library context. invalue must be > const int *. A non-zero value pointed to by invalue tells the library to create > a context for a server. > > However tls2 creates a new context for any non-NULL argument, even for > ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0). See > https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_45/libraries… I see no disagreement between the code and the documentation. Please elaborate, otherwise this ITS will be closed. -- -- 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#8805) Documentation for LDAP_OPT_X_TLS_NEWCTX is wrong
by cheimes＠redhat.com 15 Feb '18

15 Feb '18

Full_Name: Christian Heimes Version: 2.4.45 OS: Fedora URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:16b8:607e:f300:6312:6da:8e63:dfa2) The documentation for ldap_set_option LDAP_OPT_X_TLS_NEWCTX is wrong or at least misleading. The man page https://linux.die.net/man/3/ldap_set_option describes the option as: > Instructs the library to create a new TLS library context. invalue must be const int *. A non-zero value pointed to by invalue tells the library to create a context for a server. However tls2 creates a new context for any non-NULL argument, even for ldap_set_option(l, LDAP_OPT_X_TLS_NEWCTX, 0). See https://github.com/openldap/openldap/blob/OPENLDAP_REL_ENG_2_4_45/libraries…

1 0

Re: (ITS#7625) ppolicy doesn't support changing olcPasswordHash without restart
by ghenadii.batalski＠gmail.com 15 Feb '18

15 Feb '18

--94eb2c07ce7efcc3bb056541f87a Content-Type: text/plain; charset="UTF-8" Hello, today i faced the same problem but because of multiple *olcPasswordHash *entries. This caused the *userPassword *attribute was created multiple times for a single password change request: once for each hash algorithm declared in *olcPasswordHash* By the way, restarts didn't help. Regards, Gena --94eb2c07ce7efcc3bb056541f87a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello,<div><br></div><div>today i faced the same problem b= ut because of multiple=C2=A0<b>olcPasswordHash </b>entries. This caused the= =C2=A0<b>userPassword=C2=A0</b>attribute was created multiple times for a s= ingle password change request: once for each hash algorithm declared in=C2= =A0 <b style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:smal= l;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;= letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;= white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial">olcPasswordHash</b>= </div><div><br></div><div>By the way, restarts didn't help.</div><div><= br></div><div>Regards,</div><div><br></div><div>Gena</div><div><br></div><d= iv><br></div></div> --94eb2c07ce7efcc3bb056541f87a--

1 0

(ITS#8804) repeated crashes using chaning
by klaus.jungbauer＠is4it.de 13 Feb '18

13 Feb '18

Full_Name: Klaus Jungbauer Version: 2.4.45 OS: RHEL 7.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.135.30.210) I tried to use slapd within a productive environment where the slapd uses its mdb to resolve technical accounts and netgroups while real user accounts have to be resolved at AD. To do this a proxy was configured with chaining to resolve referrals. This configuration leads to very often crashes within an interval from 3 to 60 seconds (!): slapd: chain.c:226: ldap_chain_uri_cmp: Assertion `!((&li2->li_bvuri[ 0 ])->bv_val == ((void *)0))' failed. Using gdb i can see the crashes were caused by chain.c:226 or 227 coming from chain.c:831. Going deeper i saw that the assert checking li_bvuri uses a pointer at li_bvuri.bv_val which was an allocated mem at insertion time of node to tree which gets freed at chain:893. This points to a strange memory (mis)management. As a quick and dirty hack i changed chain:893 and chain.c:620 from 'ldap_memfree( li.li_uri );' to 'if ( temporary ) ldap_memfree( li.li_uri );' and inserted 'if (li2->li_bvuri[0].bv_len == 0 || li2->li_bvuri[0].bv_val == NULL) return -1;' below chain.c:225. With this changes slapd runs about half a day. Adding a Debug statement like 'Debug( 256, "#### uri_cmp: li2->li_bvuri[0].{bv_len=%d, bv_val='%s'}\n", li2->li_bvuri[0].bv_len, li2->li_bvuri[0].bv_val, 0 );' at end of chain.c:225 shows strange outputs like: 5a82a1de #### uri_cmp: li2->li_bvuri[0].{bv_len=-967084369, bv_val='(null)'} I expect another place in code adds nodes to tree too - with unresolved pointers. cn=config was created by slaptest from slapd.conf. I uploaded slapd.conf as slapd.conf_chain_provider__klaus.jungbauer(a)is4it.de to your ftp server. See RedHat Ticket #02027931 too. What do you need on additional files like config, logs, ...? Kind regards Klaus Jungbauer

1 0

Re: (ITS#8486) Syncprov sessionlog is inefficient, kills perf
by quanah＠symas.com 10 Feb '18

10 Feb '18

Using the patch in the openldap-scratch repository, this is no longer a problem. Test case: 2 masters with identical DBs Approximately 4 million user DB Modify every user on master 1 (replicated to master 2) Stop master 2, reload it with the original DB Let time pass so the accesslog DB empties out a record of all changes Start master 2 master 2 will then start querying the sesison log to find any deleted entries while this is ongoing, perform 4 concurrent queries against master 1 (in this case, a search against the entire DB with filter "(uid=*)" requesting 1.1 All four searches execute w/o issue once this patch is in place. Master 2 logs: Feb 10 19:09:54 anvil2 systemd[1]: Started LSB: Symas OpenLDAP. Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 delta-sync lost sync, switching to REFRESH Feb 10 19:09:54 anvil2 slapd[5580]: do_syncrep2: rid=100 (4096) Content Sync Refresh Required --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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