- openldap-bugs - openldap.org

Re: (ITS#8618) ldapsearch - unexpected behavior with
by andrew.lawrence＠siemens.com 02 Mar '18

02 Mar '18

--_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: multipart/alternative; boundary="_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_" --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe the following patch addresses this problem. I am still a bit conf= used about what constitutes a DNS name. Alex has suggested they should cont= ain an underscore. My colleague who reviewed the code had a different opini= on. I am also not sure what to do about copyright headers and whether it is acc= eptable or not for me to add them into the files. >From b3d02c8478edaa877b39f3d8824b54dc7b70146d Mon Sep 17 00:00:00 2001 From: Andrew Lawrence <andrew.lawrence(a)siemens.com> Date: Thu, 25 Jan 2018 22:15:14 +0000 Subject: [PATCH] Added host name validation Removed spurious include Fixed review comments Fixed additional review comments regarding errorcode and underscore --- clients/tools/common.c | 14 ++++++++++++-- include/ldap_pvt.h | 4 ++++ libraries/libldap/url.c | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/clients/tools/common.c b/clients/tools/common.c index 5eb41aa..821b006 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -5,6 +5,7 @@ * Copyright 1998-2017 The OpenLDAP Foundation. * Portions Copyright 2003 Kurt D. Zeilenga. * Portions Copyright 2003 IBM Corporation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -1242,7 +1243,16 @@ tool_conn_setup( int dont, void (*private_setup)( LD= AP * ) ) int rc; if( ( ldaphost !=3D NULL || ldapport ) && ( ldapuri =3D=3D N= ULL ) ) { - /* construct URL */ + + rc =3D ldap_validate_hostname(ldaphost); + if (rc !=3D LDAP_URL_SUCCESS) { + fprintf( stderr, + "Invalid host name %s\n", + ldaphost); + exit( EXIT_FAILURE ); + } + + /* construct URL */ LDAPURLDesc url; memset( &url, 0, sizeof(url)); @@ -1394,7 +1404,7 @@ dnssrv_free:; fprintf( stderr, "Could not create LDAP session handle for URI= =3D%s (%d): %s\n", ldapuri, rc, ldap_err2string(rc) ); - exit( EXIT_FAILURE ); + exit( EXIT_FAILURE ); } if( private_setup ) private_setup( ld ); diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h index f1d93ac..6d1a6cb 100644 --- a/include/ldap_pvt.h +++ b/include/ldap_pvt.h @@ -2,6 +2,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -68,6 +69,9 @@ LDAP_F (int) ldap_url_parselist_ext LDAP_P(( const char *sep, unsigned flags )); +LDAP_F (int) ldap_validate_hostname LDAP_P(( + const char *hostname )); + LDAP_F (char *) ldap_url_list2urls LDAP_P(( struct ldap_url_desc *ludlist )); diff --git a/libraries/libldap/url.c b/libraries/libldap/url.c index b65e2b9..2702fec 100644 --- a/libraries/libldap/url.c +++ b/libraries/libldap/url.c @@ -3,6 +3,7 @@ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2017 The OpenLDAP Foundation. + * Portions Copyright 2018 Siemens Rail Automation Holdings Limited. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,7 @@ #include <stdio.h> + #include <ac/stdlib.h> #include <ac/ctype.h> @@ -1325,6 +1327,36 @@ ldap_url_parselist_ext (LDAPURLDesc **ludlist, const= char *url, const char *sep, } int +ldap_validate_hostname (const char *url) +{ + assert( url !=3D NULL ); + + // Empty host names are invalid + if (strlen(url) =3D=3D 0) { + return LDAP_URL_ERR_BADHOST; + } + + int prevalnum =3D 0; + int labelcount =3D 0; + int i; + + for (i=3D0; url[i] !=3D '\0'; i++) { + if (!(isalnum(url[i]) || url[i] =3D=3D '.' || url[i] =3D=3D= '-') || + (labelcount =3D=3D 0 && url[i] =3D=3D '.'&& !(i =3D=3D 0= && url[i+1] =3D=3D '\0')) || + i =3D=3D 255 || labelcount =3D=3D 63) { + // We have an invalid hostname. Fail. + return LDAP_URL_ERR_BADHOST; + } else if (url[i] =3D=3D '.') { + labelcount =3D 0; + } else { + labelcount++; + } + } + + return LDAP_URL_SUCCESS; +} + +int ldap_url_parsehosts( LDAPURLDesc **ludlist, const char *hosts, -- libgit2 0.26.0 With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, Gro=DFbritannien und Nordirland mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation<http://www.siemens.com/rail-automation> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> www.siemens.com/ingenuityforlife Siemens Rail Automation Holdings Limited - registered office: Faraday House= , Sir William Siemens Square, Frimley Camberley GU16 8QD. Registered No. 00= 016033 --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> I believe the follo= wing patch addresses this problem. I am still a bit confused about what con= stitutes a DNS name. Alex has suggested they should contain an underscore. My colleague who reviewed the code had a different = opinion.<o:p></o:p> <o:p> </o:p></= span> I am also not sure = what to do about copyright headers and whether it is acceptable or not for = me to add them into the files.<o:p></o:p> <o:p> </o:p></= span> From b3d02c8478edaa= 877b39f3d8824b54dc7b70146d Mon Sep 17 00:00:00 2001<o:p></o:p> From: Andrew Lawren= ce <andrew.lawrence(a)siemens.com><o:p></o:p> Date: Thu, 25 Jan 2= 018 22:15:14 +0000<o:p></o:p> Subject: [PATCH] Ad= ded host name validation<o:p></o:p> <o:p> </o:p></= span> Removed spurious in= clude<o:p></o:p> <o:p> </o:p></= span> Fixed review commen= ts<o:p></o:p> <o:p> </o:p></= span> Fixed additional re= view comments regarding errorcode and underscore<o:p></o:p> ---<o:p></o:p></spa= n> clients/tools/commo= n.c  | 14 ++++++++++++= --<o:p></o:p> include/ldap_pvt.h&= nbsp;     |  4 ++++<o:p></o:p></sp= an> libraries/libldap/u= rl.c | 32 +++++++++++++= +++++++++++++++= ++++<o:p></o:p> 3 files changed, 48= insertions(+), 2 deletions(-)<o:p></o:p> <o:p> </o:p></= span> diff --git a/client= s/tools/common.c b/clients/tools/common.c<o:p></o:p> index 5eb41aa..821b= 006 100644<o:p></o:p> --- a/clients/tools= /common.c<o:p></o:p> +++ b/c= lients/tools/common.c<o:p></o:p> @@ -5,6 +5,7 @@= <o:p></o:p>   * Copyright = 1998-2017 The OpenLDAP Foundation.<o:p></o:p>   * Portions C= opyright 2003 Kurt D. Zeilenga.<o:p></o:p>   * Portions C= opyright 2003 IBM Corporation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -1242,7 +124= 3,16 @@ tool_conn_setup( int dont, void (*private_setup)( LDAP * ) )<o:p></= o:p>    &= nbsp;          int rc;<o:p></o= :p> <o:p></o:p><= /p>    &= nbsp;           if( ( lda= phost !=3D NULL || ldapport ) && ( ldapuri =3D=3D NULL ) ) {<o:p></= o:p> -   =             &nb= sp;      /* construct URL */<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;           &nbsp= ;       rc =3D ldap_validate_hostname(ldaphos= t);<o:p></o:p> +  &n= bsp;           &nbsp= ;       if (rc !=3D LDAP_URL_SUCCESS) {<o:p><= /o:p> +  &n= bsp;           &nbsp= ;            &n= bsp;  fprintf( stderr,<o:p></o:p> +  &n= bsp;           &nbsp= ;            &n= bsp;     "Invalid host name %s\n",<o:p></o:p></spa= n> +  &n= bsp;           &nbsp= ;            &n= bsp;         ldaphost);<o:p></o:p><= /span> +  &n= bsp;           &nbsp= ;            &n= bsp;  exit( EXIT_FAILURE );<o:p></o:p> +  &n= bsp;            &nbs= p;      }<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;            &nbs= p;      /* construct URL */<o:p></o:p>    &= nbsp;           &nbs= p;      LDAPURLDesc url;<o:p></o:p>    &= nbsp;           &nbs= p;      memset( &url, 0, sizeof(url));<o:p></o= :p> <o:p></o:p><= /p> @@ -1394,7 +140= 4,7 @@ dnssrv_free:;<o:p></o:p>    &= nbsp;           &nbs= p;      fprintf( stderr,<o:p></o:p>    &= nbsp;           &nbs= p;            &= nbsp; "Could not create LDAP session handle for URI=3D%s (%d): %s\n&qu= ot;,<o:p></o:p>    &= nbsp;           &nbs= p;            &= nbsp; ldapuri, rc, ldap_err2string(rc) );<o:p></o:p> -   =             &nb= sp;      exit( EXIT_FAILURE );<o:p></o:p></= p> +  &n= bsp;            &nbs= p;     exit( EXIT_FAILURE );<o:p></o:p>    &= nbsp;          }<o:p></o:p></s= pan> <o:p></o:p><= /p>    &= nbsp;           if( priva= te_setup ) private_setup( ld );<o:p></o:p> diff --git a/includ= e/ldap_pvt.h b/include/ldap_pvt.h<o:p></o:p> index f1d93ac..6d1a= 6cb 100644<o:p></o:p> --- a/include/ldap_= pvt.h<o:p></o:p> +++ b/i= nclude/ldap_pvt.h<o:p></o:p> @@ -2,6 +2,7 @@= <o:p></o:p> /* This work is par= t of OpenLDAP Software <http://www.openldap.org/>.<o:p></o:p><= /p>   * <o:p></o:p>   * Copyr= ight 1998-2017 The OpenLDAP Foundation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -68,6 +69,9 = @@ LDAP_F (int) ldap_url_parselist_ext LDAP_P((<o:p></o:p>    &= nbsp;   const char *sep,<o:p></o:p>    &= nbsp;   unsigned flags ));<o:p></o:p> <o:p></o:p><= /p> +LDAP_F (int) l= dap_validate_hostname LDAP_P((<o:p></o:p> +  &n= bsp;    const char *hostname ));<o:p></o:p> +<o:p></o:p></s= pan> LDAP_F (char *) lda= p_url_list2urls LDAP_P((<o:p></o:p>    &= nbsp;   struct ldap_url_desc *ludlist ));<o:p></o:p> <o:p></o:p><= /p> diff --git a/librar= ies/libldap/url.c b/libraries/libldap/url.c<o:p></o:p> index b65e2b9..2702= fec 100644<o:p></o:p> --- a/libraries/lib= ldap/url.c<o:p></o:p> +++ b/l= ibraries/libldap/url.c<o:p></o:p> @@ -3,6 +3,7 @@= <o:p></o:p> /* This work is par= t of OpenLDAP Software <http://www.openldap.org/>.<o:p></o:p><= /p>   *<o:p></o:p>=   * Copyright = 1998-2017 The OpenLDAP Foundation.<o:p></o:p> + * Portions Co= pyright 2018 Siemens Rail Automation Holdings Limited.<o:p></o:p></p= >   * All rights= reserved.<o:p></o:p>   *<o:p></o:p>=   * Redistribu= tion and use in source and binary forms, with or without<o:p></o:p><= /p> @@ -36,6 +37,7 = @@<o:p></o:p> <o:p></o:p><= /p>  #include <= stdio.h><o:p></o:p> <o:p></o:p><= /p> +<o:p></o:p></s= pan> #include <ac/std= lib.h><o:p></o:p> #include <ac/cty= pe.h><o:p></o:p> <o:p></o:p><= /p> @@ -1325,6 +132= 7,36 @@ ldap_url_parselist_ext (LDAPURLDesc **ludlist, const char *url, con= st char *sep,<o:p></o:p> }<o:p></o:p>= <o:p></o:p><= /p>  int<o:p></o:p= > +ldap_validate_= hostname (const char *url)<o:p></o:p> +{<o:p></o:p></= span> +  &n= bsp;    assert( url !=3D NULL );<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;    // Empty host names are invalid<o:p></o:p></p= > +  &n= bsp;    if (strlen(url) =3D=3D 0) {<o:p></o:p> +  &n= bsp;           return LDA= P_URL_ERR_BADHOST;<o:p></o:p> +  &n= bsp;    }<o:p></o:p> +  &n= bsp;    <o:p></o:p> +  &n= bsp;     int prevalnum =3D 0;<o:p></o:p> +  &n= bsp;    int labelcount =3D 0;<o:p></o:p> +  &n= bsp;    int i;<o:p></o:p> +  &n= bsp;    <o:p></o:p> +  &n= bsp;    for (i=3D0; url[i] !=3D '\0'; i++) {<o:p></o= :p> +  &n= bsp;            if (!(isa= lnum(url[i]) || url[i] =3D=3D '.' || url[i] =3D=3D '-') ||<o:p></o:p></span= > +  &n= bsp;            &nbs= p;  (labelcount =3D=3D 0 && url[i] =3D=3D '.'&& !(i = =3D=3D 0 && url[i+1] =3D=3D '\0')) ||<o:p></o:p> +  &n= bsp;            &nbs= p;  i =3D=3D 255 || labelcount =3D=3D 63) { <o:p></o:p> +  &n= bsp;           &nbsp= ;       // We have an invalid hostname. Fail.= <o:p></o:p> +  &n= bsp;            &nbs= p;      return LDAP_URL_ERR_BADHOST;<o:p></o:p></s= pan> +  &n= bsp;           } else if = (url[i] =3D=3D '.') {<o:p></o:p> +  &n= bsp;           &nbsp= ;       labelcount =3D 0;<o:p></o:p></= p> +  &n= bsp;           } else {<o= :p></o:p> +  &n= bsp;           &nbsp= ;       labelcount++;<o:p></o:p></spa= n> +  &n= bsp;           } &nb= sp; <o:p></o:p> +  &n= bsp;    }<o:p></o:p> +<o:p></o:p></s= pan> +  &n= bsp;    return LDAP_URL_SUCCESS;<o:p></o:p> +}<o:p></o:p></= span> +<o:p></o:p></s= pan> +int<o:p></o:p>= ldap_url_parsehosts= (<o:p></o:p>    &= nbsp;   LDAPURLDesc **ludlist,<o:p></o:p>    &= nbsp;   const char *hosts,<o:p></o:p> --<o:p></o:p></span= > libgit2 0.26.0<o:p>= </o:p> <o:p> </o:p> <o:p> </o:p> With best rega= rds, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, Gro=DFbritannien und Nordirland <a href=3D"mailto:andrew.lawrence@siemens.com">m= ailto:andrew.lawrence@siemens.com</a> <a href=3D"http://www.siemens.com/rail-automation">www.siemens.com/rail-automation</a> <a href=3D"https://siemens.com/ingenuityforlife">www.siemens.com/ingenuityforlife</a> <img border=3D"0" width=3D"300= " height=3D"109" id=3D"_x0000_i1025" src=3D"cid:image003.png@01D3B24C.628B2= 0A0" alt=3D"www.siemens.com/ingenuityforlife"> Siemens Rail Automation Holding= s Limited - registered office: Faraday House, Sir William Siemens Square, F= rimley Camberley GU16 8QD. Registered No. 00016033<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_-- --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=9561; creation-date="Fri, 02 Mar 2018 17:32:42 GMT"; modification-date="Fri, 02 Mar 2018 17:32:42 GMT" Content-ID: <image003.png(a)01D3B24C.628B20A0> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASwAAABtCAYAAAAbDlwIAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACTZSURBVHja 7Z0HfFVV8sdDEwEV7AURsQOWdYtrR1HsiAX76q5rL+ti278FlCotQAgdpPcWeu8ltEDoEDpKgNB7 lTD/+Z73brh5vEBCQPLi/Pjczwv33XvOmXPu/O7MnDnnRYnBYDBECKKsCwwGQ6TACMtgMEQMjLAM BkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAI y2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQM jLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZD xMAIy2AwRAzOGmH9dvSobNi3T5bt3CmLtm+Xpfr5y969suPQoZPee1SPI3o//1LdcWKkBo+jmfzn rnflZ66s1KOpp9wP3Juu3qB8GcqdJVlEUuVohuWFypKaenI5jh4NtPNIWtlHMyXnoSNHZL2Orxvv HVkbb4PhrBAWJLNg2zbptWKFVJsxQz4cM1b+MXy4vDJsmLwxYoS8O3asVJk8RWrNni2dly2T2Zs3 yyGfEvEX5FY/MVG+nzZdqul1VafPkB+nTZMey5fLpv3709V3UO/tu2qVu6bqjJnu+nTHnPBH1Zkz 9Z7pMvrXX2Xvb7+5sg5rWTM2bZJo6oyPP3a9+/80qT5rlozZsCFT/bD54EHprn3wg7abetLVq+eG rVkjOw8fTnfPVr2nl8r4vdZddVZCJmSZo+cTVG7tn4QEiU9JSVfedJWl4ew5UnVqvLvO1a/X/qDt 6b96tSPs48ZPj6QdO6T5vHny/ZQp2vZpEr1gvqzdsyesnAe1jLlbt0rnpKXyrcr1wZgxOt4j5BUd 89d1vN8JjndN7bvOy5bLEi3bYMgRhLVZ36S9lYTeGDxYrv25vUTFNJWoeg0kqlZtiapRU6Jq1pKo Oj9JVH09V7++XNSihbw/ebJsUUX1cFgVoKcqetFWrfXe+hLVrLle21CifvpJHhk0SOYqGfqB0lcc OTJQZsNGges5YptJVFOO2PBHA8qsK1UmTpQNQRLco8TVcP48ubSZ3le7jkQ1bxE4KC+6saujsirh Dl97M8L4Devl2q5dVYZ6EtWo8bGy+FvrfV+JfHUICSSpRVJp0OBA3fTdyWThfJMYiaqr/dSkidSc OzetLKiorpLOhdRJ/3Mtf1Ouln9Xt24yY3OKe8H4cUj/P0DJ7MZ2P0tU9Rpadj25pEMnGb9+/XEy phw8IJ2XLJFXBg6UK9q2DbSFMaP9jLV/vPX8pa3byI9KoEfFYDjLhIV10mTBArmhTVvJx4MKIaBU jQKKzoOfdvD/aj+4485+/WStug1+wsLKuLhFS6fYroygEjwycIAkhiGsp0aMDFzj1ekUWRWzYXTg XLiDNv7wo3yqxLHOR1gNVMmvpAy+j/WThP5do5aUVsWMW73KtTMj4Aq30HKiohsF6oIkvHbRJpXl w9FjjiMsXKjnVfkdwTRucnJZOAdZ/VDDfX6nVpifsOpoGy6CfHlZ0AbK4qhVRwo3bKgvi0nOqgsl rDi1/m5p2871D2NwRfsOMiGEsHDz6iTOkVItW0o+yqcttBOZ/ePNuHBQ1o/V5emRo44jSYPhdyUs lHdMcrLc07FjQDl40/I2V4Ur1KaN3NKjp5RXRawweJDcowR1fbfuUhAi0zd42T59ZNXu3emUve+K lfrGbhd4+Fu2UtJrIgUaNJCnhw6Reeou+rFLCauyKr8jRurFMvMOSM+zbEIPrlel/0otvA0HDriy cA1jlHRLtgxad5RB/XwqEaOIhRs3lvemTJatJ4jLJKqL9NKQIQGFhSDUskgrR4kjj9b76fjxssZH 1GDZrl3y8tChAYXHsuJ67s1IFs5RPuQVGys/KUH5CStaZSnepnWgHVzrlcU9WsdNXbupO7fluLEc vHat3N6pU8BSUiIqoZbiJJ8rzDVDlNRuwqryW4MxsXKu9lPpnj3VGtbxVov4Lh3vEp07S95GjdxL 4HF1FQ+nporBcNYIC5fu7QkTpGCDgOmPcubXN/ud+uBGz58vo/XtPH3LZpm5ZYtMSUmREUpubRct kq8nTpKac+bIxn370hPWylVyBS4lBISSNYmVAo2i5dlhQ2V+GMJ6Ra0kdy2KiGKqAt3cvYd8Mm2a xC5aLI0XLpRGC9If0eo+NUpMlKmqiPuDMSwsrKZ6bUnqVAvEkRR/88nhXMNGUlYJOHHLlgz7o1VS klzM9R7hQr5eOdrGPEqW/9H+WhtCWMshrGHDAgSEHJCLkn5pleUzlaWRtq2JXxb39wInR+MF82W2 r00QFtdeDalQHmXRDtrAp7bhXH0RfDNzuqwPEnYaGUFYSjKO6PS6Euo++glr+e5d8sboUQF3Lyhj fiXQu/r2lZaLF7vxnqFtYbwn6XgP/fVXablwgXyh7ndT/Txw5IhppeHsERaxl9K9ewfcAt78Sh6F oqPlo4kTZG9qxg8ngelfVWkPBAnjOMLCLXKE1VQKaHkVMyCsl/2ExaGK9oxadJBkVpCOsBpEB5Qb 4oB0OBe0+oopiUC4e8Mo3h5tz6eqmI4kIDiPePyEpWVkirCoVy2hSirLvG1bsyQLhNXYIywsNs/q pEyPfPV8SbWkRiihhCUsXPIwhDVuw3q5pkuXQDsZb5XnvKZN5XMl1RMh5cB+Wb9vr1lYhrNLWPO2 bZOS6uY5N8tZOOoaKIFUUvdmdPI62Xk489Pa2SIsL0CthPX84MEyJyTelSXCqt9Q8qpi5/e7cxCW 1lNQFfVFtTCWKsGEYowq8/1qWTpl177Io/fl13LyelZaVglLLdaXVJakXTuzT1jOhWx+TBZcOf0O t3jToUAs60gmCGu4ElzR9h0C40OZ2ifnqUv68sgRMmNTihsTgyHHEtbiHTvkpp69AhYWpKGKmUcf 5HP0eKBPX4mZmygLlTz2KSGcLNx6WghLlfzZQYOUsLJmlaQjLFXWIqrU1yn5lOjeXc6FPFBODlXi yzt2lKG//JJOHuyGL2fOkkJYHdqG/HrtNXpvcVX4ghBEMH6UVcKqrLIQkD9lwlIChziLKMmcQzs8 K4s69LubOnWWPmvWpMlwMsIaoy7flVhY0cFZWS0zj34WUbkrxPWX5uqeLtNnYp/PcjYYcgxhJe/b J88MHy55iWHxEDMljmLoQ5xPSexKffve36eP1FFlTti0yZHSGSEsyCro6lSIi5MJGze6a8jzIm4S ehxJTU1HOGmE1aaNmxG8WJX9ubFj5MMpU+Q62oMFiVzqEkI6NadPl22HDvr6Ya9UGDgokIYREyOX q7tF2sa96tLl9dyxU3AJn+4fJ9NTUlzfcHjt3x/8JGEzNKcqjbDatXPB7sLaL48OGSqPDR8hVzI+ Xt9qe/LqGFXRdro+0fsIut/WKWPCmqtj8NigwZKP7+l3rC1nPTaX/CrblUpcj/TvL/Vnz5b5mzeL wZCjCOugPug9V66QEq1aBaavIQ2UgoeYqfnglPxVqhwP9+4j38VPkykbN4TNXs8WYVFXcOaseOcu 8syo0fJRfLy8q4Tzjiokx7/1eH3sWPlMP1HCg754SjoLq0ZNOV/l+ffkSTJq3Tp5ZMCAgBxe/EeV 9TE9Fx+Mk6Hs7ZOSpBTfV68hBZs3c/lho5KTpZKSuXO/skpYkJzWdbXK8qzK8v7UqfKeJ4t+vj1x oryphFpl2jTnlocnrJ9dOsH52j+fTJosfZWMKpM6Adl4bmqdn+R2tZiGaFtx5oar5Xgbs4QZEBZ9 /vPixVKkadNA+gf9wXhRVsyxFIwSzZrJ42ph105IkGn6orLIlSFHEBbYffiQy6AuTt5PnTrBqfZm AYuEhzlo+eDinKtE9ESvnhIzb64sD8lFyjZhcT1K2rxlME+pbjAfKHjwd9Vqkl+VtOGcObLdF29J R1i1akleleXF0aNdlvf/zZolRZANhYRMlHQuVkus1dKl7l7SHCqNHiMFabOWX0q/67J8uctXqjw0 SEJZJSxPlhaeLPWOyVK/fiBfS+tC9t4rV2ZMWBCo1vlPJWrqbJyYKPmwFpGFOrTN+bX8jydNcvfO 27pF7uraLTALGIawQMr+/fKZkublseSs1T6WtEt9HEHXnKOYEttTSlytFy2Udfv3mUYazj5hgWR9 iOslzpE/6du6GK4hSoYC8/B60/tYDZxXl6uYPuz/VSVZu3t32ts324TFWz6o5Hm0nrxqJeQhhuMd KJEq+UW160gjdVm2ZUhYqoQxTeThIUNknbq8E9W9/AtxG6wOvodEtKyv1GoBvyipkX7gZFOyK9er l1tHifVZkex1L/B9yoTVMNj+oBxKWHloY7VqUlBl73ciwlJrkb6oQPB+506JVzftrl69A7IQb2Nc 6tSVcj16OHJep+16VC1hl2OVAWEB5KuhRH6buoTnM6vqkkeDrrkX2A+6tVhixVu2lJozpssWXxqF wXDWCAvgYrGGDZfrDlWAC/QBzgtJeDNKrYNuCIqib/BLVCFqz5gpm4IPcbZjWCiKln1Jx45y94A4 eVoJ4Aklnce9Y+hQKde/v0vsZD3ffl9qwnGE1aSJ3D9okIvREQf794gRASX30hy0/S/GDZBEbdPg 1aulODKpkudp3FheGzfOlUmO2UP94wLKfCqEpZ+Xduwk96j7+aTK/8TQY3I8pq5d+X79pPKoUW4N 5AkJS8ssN2CgzN26zc0ERifMlry8VLCyIBZtX3Gtq6aSOORUoV//gIV0AsJy4639N2ldsnyg1tut Sujn6ZilG28vlw3rS9tRSq3U6Hnz1SK3mURDDiAsD6zPS9Q3eeOEBKdUFzRvHlAAT0G8xFBV8Bu6 dpeJGzZmn7C8tXeqnOXj4qTv2jWyQq23FUoEy71j9y5nZazSz13qrh31BauPJ6wYR1jrg4mtPyXO lTzNmh3LqNfP6zt1lsqqrBWURAoFl/SUUPmaLF7s7lmybZvcq+6Qm4w4lVlCJZLHVJah69YFZNl9 TA4+2RlhtZ4PnZELS1hKcLO3BmZOIaDSPXoEEmSdBdxa8ukY3dCjp3w8darcQZtjAkttSnTNmLC8 upJVloSUFKk9c6aU6907EN/CsqJsz00MrqO8Q627+Vu3isGQYwjLw04lBXYRaLNggVSM6x+IA7nU h6C7EMzd6pS0zF2PvdNvVfbTGlhEvCDk2pMhQ8IKEsuI9evlbyTIQrxBVyq/klBBlaOAl/ag7toL g4bIymCOFqR9d58+p05YWteLKsty3/KlzCAcYT0EYQWz4Ynd/aTu+3lqDabN7AZnMi/v0lUuVCLO G0zhOBlh+bFZLeUpem3s3ER5ROXO1zS46NpLnFUCLqr/767jvd8y3g05jbD8mLxxg7w6cqQUhVQa x6RNq6OczZXQQOppIizysGadYPlMVghrXZBYcFu/nTIlveUQDKS7+JlaJHljY6WGbxHyHCWse7JJ WC9oGxZlcVuWkxEWWLxtq9xOwq+3dhFCoc4gweQNvlCyQlj++kevT5aX1I0ujKXGEUynuEj/jk5M lO22T5bhbBAWbhWxjIOZWHLRfNEiucYFrBsEyCg469Z2yZLTR1hq5VQaPFhmbc1G4qiPsH7xEQv7 fBWBeNJicm2OxeRIwuzaVfr98svpIywts7LKsuRUE0dPQFj0HTs8FPN2xPDWPHopFRlYWMTA9mdi vGlDmyWL5BIv1SG4hrGYjlMbfQ72WGKp4WwQFg/vZH2g+6syE8dgMTTKwAO5N3gQZF26c4e8PW6c nA+xoCQoub7dL2zfXoYElfxIdoPuwbVtd/fpK22SktzOCTM3bZIZ2q5jxyaZvnGjxK/f4DKyvQ38 9maCsNiP61E9lw+rxIvHBZfcIEsoEWWbsFTB71NZOixf7uSYdZwsKS6pNH7DRlmupHbQ52adjLAA Y1KO9tWtf8x1847grhahhLVNLaNxycluvHF5t2Uw3nO0798YMyYQ2/MWpjdoINd07CTjk9fbvliG s0NY5CB9OW2alNaHvGz7DvLkiJHypipklenT5JtZs+T/Zs6Uf0+aLA8OGuh2MWDZjjczVaBOHXUb hqdZENlOawjGYYro/dequ3Nrr95ud4Uy/qNnLynTpauU1rZ8PnGS1h2IN+1TZT8ZYe1SZWwyb54U i4kJxN+8tANtayG9r8/Klen2e8oWYQW3gzlPZSmlspTVdh8nC0e3blJa+/MrUkT27skSYZHrjwt7 WfNgnpyXTHoCwlq5Z49LR7lFXzy3duokz4wapeM7ST4PjvfXOt5v6//v7R8nRVu1OjbeasUVql9f Xh87TpL37TfNNJwdwiLQ+tb48YGsZxIZlTjyqWJeoA/8xS1bykWsK3T7Jfk2siMBUq//c5cuMm7d urQALCv5++ibO/1+WI0lv76ZmdYPtx/WC/79sLyUA9+eV2E3viO59bvv5Yl+cTJzS8B1ZPcFNiG8 hjLY10vvv3vAgOO2B56nSn9r9+7H2qdyFWBmUl23BSGxpgSC7uQ8QQbBrW8gj0/GjZc1YXYcdfto eTuthsqS0YaE9OX3VeWZ/v3TrTmMVsK6irWEP1Z3ZT4QFxc2rkebn9R707LWfcuIqJNM+4k+wlq2 e7e8zi6vWmdU9eruOsa3aHC8L1Q5C3hJtjGxgYN0kJo1nTU34yTLswxGWGcUuASfxcdLfhRNScBl SKPwLNMJ7izqttvlPErH4mG1UJ7u2096rFol/rkiCKvb0qVSiIedMiAFrB1Vunvj+klCSFyKHUfL k0lOtrW3P1Ojxsd2+8yIsGoHCatv/zTC2nPkN6mdOEcu4P6v/+cU+MZevdJtMAgIFr+lFhLJlp5s 5yghxarltSMkv4glKWVZl0dfUC+Kq7L8S63QlSHlElh/sl+/QJn1G2ROFo+wVJaKSjpJvh0kasxN VHdM+/HLr1yZZXv2lPjNm8KOYcPERCmMRUufUzf1Mp4q2/lqcY1VF9ADGw9+OH5CgOBoa0bjjawN AwmlV+nLhN1UB/q2sjEYzgphEbPgByUq9Okrt7RuLdepdXS1vqFZBHu5vnk5rmrRQkrqm/tmdRmf 0Ae3ekKCiy+FgjfvyLVr5UElitLqCpXp3kPK6D23aZnvjh93XPCZuMnHU+PdNWU6dgpcf7IDN0qt hjJt2sgXEyamuYRYeR2SkqR8D70mtrkr88UxY1ziqB8HlFR7rVwh5Tp0lJL16kkpJdcHyS0KY72w S8Vr6ubhspVRt66MklfZdu2k1vTpLoPeD/KpqqilSrvKdO2aOVk41GUro6Ty1cSJ6dzMn5cluX4s oxYOZb46ZrS61OG33Jmt7XxPZS2j40cbXR+p9VtaXcryAwa6Rese2Fa53aLFcp/WfYtacKX0YLyv 0PG+jPHWTzfeeq5Mx45SUd3q2uoqrsjixIHBCOuMAOOeXTuX79whE5PXSb8VK6WtPtAxanHU0zc3 v4DTbP586bJkiYzVNyx5TRntOklZW9XFnK0KQj7PtI0pEs+OpXosDbNlCfGipB07Zep6vTZ4fdqR kvERz7VqNazwlcmOB7Rttn4/Vd1UriGX61CYtrJGcOyaNdJZXcieahGO0/aFyyvaqxbXQiXmKfr9 NAL9GwLtXK2W0MGQ6+lDJgGm6rXxem2mZdFruYd7/f3K0hkny6/rnKyLlJT2ZJBhjuwbVfbpyevd LqyubP2k3fyykX+PK2aF6TN+AWe8jid78LdetEga63jXZbznzpVYHe+u2i+TtN4t+/fbLqOGnENY oYRz8EiqKsZvTqm3BQ9cNx7y1Fw0N3Q4qLgQ1R81JoPUkBGzgseN9xFLWzBkHfbLzwaDIWJghGUw GCIGRlgGgyFiYIRlMBgiBkZYBoMhYmCEZTAYIgZGWAaDIWKQqwmLJMZ169bJ8uXLZecfLJMa2ffv 3y979+6V307zVi0HDhyQ7du3n/ZyDYaTIVcTFiT1+eefy6OPPio9evRIt+VxbsERfi8wTKb4xo0b ncwdO3aUX3x7cGUXhw8floEDB0q9evVk1KhRcvDgwTPSr6mpqY4QU0P21eL/4eSlDbt375a1a9c6 Mk21n7zPlcjVhDV37lz5+9//LlFRUfLf//43Vz7EK1askDFjxkhSUlI6RR4yZIhcd911csMNN8iE CRNOS11YVv369ZP77rtPLrnkErn33nulZ8+esm/f6f15Ll40tH/48OGyNWRN6XqWMU2bJosXL043 nitXrpSPP/5Y/va3v0mVKlVkSXDTR0PuQq4lLCyBAQMGOIW96KKLpGHDhrnSwoqPj5dXX31Vnn76 aUdcyJicnCzvvPOOI2q+W7Vq1WmpC0utQoUKcsEFF8iDDz4oL730ktSoUUO2bdt22uTZs2eP/Pjj j3LnnXc66ziUsJDlm2++ce34+eefnTUF2rdvL0WLFpWCBQtK2bJl3f8P26/v5DrkWsLCPahbt64U K1ZMHnjgAZkxY0aulHP16tVSrVo1eeyxx6Rr166OsOLi4qR48eJy+eWXy8yZM09LPcTCcC8hq2ee eUamTp0qiYmJznrbE7J3V3awcOFCufbaayVv3rxSs2ZNORSyt/uOHTukefPmctddd8l//vMf2cAi 9AULpFy5cnLeeec5smvUqJGzzojhGXIXci1hpaSkSKVKlZyV8a9//Us2b978u9SL2/R7v9mpE0Vn cgEQX0JurJQNWfyBiBMRSfny5eWcc86Rtm3bnjE5KBuLGAsKlz4cIK2JEyfKyJEjHVk2aNDAyfvn P//ZWZcA99gsrNyHXEtYxHZKlSrlHuTatWs7y8P9IMbBg+4hP5TFX2XhvhMpAGUTR+ndu7eMHj3a EaQ/xkJ9KOSRTG6lciruK2VT51dffeXkfu+992RLFn8dKCMMGjRIChUqJFdddZUjizMB4lJPPfWU nHvuuRIdHX3CvkJO+pSxfPvttx2Rfv3116fV2jMYYf1umDJlilxxxRXOJezSpYs7RzCXmMvjjz8u nTt3znRZixYtcm9x7sHSQClClYn40Ysvvih/+tOfXFAaK2fNmjVp9aKAX375pYs5nQwQH9fh7vmJ C8Lzuzko7bJly9ICzAS/IZNHHnnEKT1xLMiT8jIiaO4h9QNCzgh8h3t9/vnnu7jSpk2bsj0+tJ1y /aQ+bNgwKVKkiKsHly4zYDxwB6+//noXqPePi9/yPGwpGEZYORUoZ7du3VwMBzdh/Pjx7jwEcvPN N6fNGnrKSHC+T58+TnH9YFqdWTDckzJlyjiXCDfz+++/l1mzZqVdxzQ/JMX3BIQJ/uKOTZo0yX0/ f/58ufXWWyVfvnyOyDwQe4EMUSwPEFT16tXloYcekm+//VaO+BS6e/fubiZs3Lhxrt3MmGFV/POf /5SEhAQXFH/33XddnAmL47bbbnMkyvefffaZ9OrVK51rPG/ePEdq//jHPxzBZ2TRcA9l0J8tWrRw 1it9hWuGC0bMjDhabGysI0cP9PfkyZPl1+DWx5Br69atXf/x4qA9/oB9mzZt3Njcfffdrm2hgJiJ m+32bR9NXO3SSy91lpmfdKdPn+7qefbZZ11IoGOHDmntMBhh5SgwcwQxEAthJgsFg3yGDh3qpuOZ RULpUbiqVavKTTfd5AipXbt26R568pgIAF922WWOPJ5//nmnUBAB9wMUjhk6zr/88svStGlTp3Af ffRRWr2tWrVyAWHqHTFihLPQqIvg9SuvvOLa5ZEV9/zlL39x5eHqeMDi+utf/+rO4/IhI4QIAaOw kBlxuw8//NCRVYkSJdz0PkTCpAP3Pffcc2kW2tKlS+WNN95w57mWeJBHWPQBhITS9+/f3xEohMsM HNYMBPDJJ5/Id9995wgU6+biiy+WkiVLuv9j0SA3biSzlFxLH0Ce9DPt4TpeKh5hYenRVsj2008/ PY5cINS33nrLWXgQPWMH2VMmMlAmVhkueZMmTVzfknZBf/DyuK5UKUeIBiOsHAfe+lhQWDq4YRAE 0+P/+9//5EJ1EWvVquWUmwcbBcFyyJ8/v3v4UVSUDTK4/fbb3WwbDzplonhch1XCrBmWEd+hqNTF TN2bb77pZqk8S4bZNFw04j9Mw3Mf90CC1MtsGC4qeVQASw8CgYhwkSAxCACiQDEvvPBC+eGHHxxh MSvoETDtpd2QLGVTp0e+XIdrjOJiAWH5oMiURxsgd3+sCzKDFMlhQ37cNNoJ6UJcWH+epcp5SAgL DkLEDf/iiy9ceVietI3rOK6++moXVxs8eLDrT/rPc3khKKxD5MF99q9MgJi8lwIWLtbXnDlzHIEx fp4c9D/EhTvsET6zw1hftB231mCEleOA64FlhaLhpgACuk888YQUVuLgTY71ceONNzpLiLc/ikXO FrEossS5n4ee71Gmli1bOuXFrYuJiXEWwdixY930ukckkCPKDinhljLLhRJi8WCdQCaQFfWigLhX 3E+ZtIkycU+x6rCmyCSHiCACys+TJ49TetoLCeNeQYT33HNPWjY7bhbKS3a/ZzFBUMjD+ddff10q V67srDLKox9CA9XIhRUJCVM27UVGXF5cPGYeIX3OQTBYP7SdGFLp0qXdAclC1p5VSH0QJ0QbbvIC d++FF15wbaSf/Offf//9NBLCBaZvSdegjRAmMS9IFDeTlAcIlGshbQgSEuMFxtgYjLByHIhzEFOC KHARAIrmWQXXXHONXHnllU55saiIiXjuEdYTb3CPsMgWhzBQQqwrrB9IDHfotddec9YRiu2RG2SH YqA8vPHvv/9+F4iHsFAkFPLhhx92iki9KBiu6y233OIC5FgeWA4oIQqJRQP5oOxYb7QB5cOVwi2F ZCFbYmpYKygy9UEUXjwJ4kImZkupG5KjvcR3vFQIP7AOifvRHkj3gw8+cPXiqnnxNqwkZMGimj17 tjuHZVm4cGFnyZHg2aFDB2fZ0d9YTXtDfhzWD9qK+0h5uJKAupGZscLlpM0QO8ACYxIE+ZG3b9++ jkghROKIvKxoH5YkpH86JgoMRlhnBASg77jjDveA42IBSMQjIQ5iR8RCPGAl8D1LO7CmiCvh2mBh QGIoO2kSKCBEgrtBNjWJk82aNXPWBy4kVkLFihVdOdyHImE18T2kBcF5wXhA4JyysWJwXWgT7g7k h/WFEnszZrhYEBiu63pVzh1B5cSSINaE5QEJQmjcC6n4ZwdR8k6dOjmCRaEzG9MhQRPXq379+mnL cLA6ISEmNch6h/xJeYCUkRmrDReavsa1PBlhcD0WJy8E+ohYFWTPi6JOnTquDQUKFHCfHiBpyBo3 ERffA2MNuWKVQmbICQHT78TqcLUhWUuBMMLKEcAFwj1DkXBvAJYBf+NeEPANl5SI20hcC4UjHoSS EQPh7c9sIZYCiotyhuYioRDUCcFgkWBt+JfEQICkRoSrl3gPyop7hhsFUEDq8Aef+Rt3Cctie/BX pLHUsCIhOc/Vos2Ux5o7P2FBNpAsioySZ2a9HRYjBImVw73+tApv8gCCwarCzfW7cySBUo9/ZvRE YOEykyBYwlidvAAYD4DVjMWKZYvFiFxYcLSLSYDQ9Yz0PbOEWNoE33mJMDYcjD9jvD3kl8INRlhn BSguDyxvVBTODxQuK4ugcY8IljMT5mVTM9OXEY5k4zf2cOl27dqVqQztzCSWhl7DTCMzolh6zNBl BvQjRIRrjKUYrm24YricfisH8JJgsiMrW/tAPLwcsDo98gZMIGAZEdfzEkZZH4q1iDUVDlwHaWMZ cg1WK5MJxADJz7JMeCOsHAWIKTsLnlE03EJv1o7AL2/rM5XpnRUyOpW+IEhPXI8Zx3B5TuHABAaW DURHTOv32PECoiHeFdoPEAzfcZ6xIZ5FPI4xOlFfQm7E/CBPrCr+b3t5RSZsx9ETgLcxKQLEhHAh sDIIgBMjizTgUpEAi6vFFjGZXRiM1cSkA6SdkYV1NkAeFu4h1iIzh4Y/BoywwgBXBuVkpo44GEpL MJzAOLNWkZgxjRvETB9T/KGu24kAQRFXIpkVNzKn7ICABUacEKuXmUDDHwNGWGFATIacLWbSmFXD rSD4S84RW55E2rYlECxBZ5InveTVrIAgPgF0LMusLho/U8ClIz7FODFT6l/eZMi9MMIKAeSEguIC oQxeZjizXbgfrF2LNJB+wOwmaRu5SbGx/gjCk+zrX19oyL0wwgqBtycTmdmkIQBmq8gwJx0gs7sI 5BQQbCYHDHfWS8jMTcDSwuqzPdz/GDDCCgEzSEyD4/55WfIkYGKhsGOBt2VMJICZNG9NJesos+oK Ggw5DUZYIeBtTZ4VGdRkauNOPfnkky6J0VtgHAlg+p5lP6Qx4AqSnmAwRDqMsMKAKXO2iSFQTcIo 6/LIYYqk+A9rBEmWJPZGSoPBkBtghJUBiImwBIblMriEkQZmBrEUQzclNBgiGUZYJwDLRAhaR+IS DlzXE217bDBEIoywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAI y2AwRAyMsAwGQ8TACMtgMEQMjLAMBkPEwAjLYDBEDIywDAZDxMAIy2AwRAyMsAwGQ8TACMtgMEQM jLAMBkPEwAjLYDBEDIywDAZDxOD/AfJ2nuAo4uJvAAAAAElFTkSuQmCC --_004_4CF710229787A0419BF92C9304DC6446E7927ADEFTHW99EI5MSXww9_--

1 0

(ITS#8812) OpenLDAP 2.4 Standalone or embedded
by muthamma.appaiah＠wellsfargo.com 02 Mar '18

02 Mar '18

Full_Name: Muthamma Version: 2.4 and 2.3 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::a) Hi team, Could you confirm if the product OpenLDAP is a stand-alone product or embedded?

1 0

Re: (ITS#8810) speeling-error
by quanah＠symas.com 24 Feb '18

24 Feb '18

--On Saturday, February 24, 2018 11:54 AM +0000 sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-180224.patch > Submission from: (NULL) (2001:470:77b3:50::65) > > > Debian Lintian found a typo in libraries/libldap/os-local.c: "errror" > should be "error" > Patch attached Hi Andreas, Please always check OpenLDAP head before filing a report. :) commit c1512eea5818c81ff19d81d8aeae1967bab7e64f Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Fri Sep 8 12:03:02 2017 -0700 Fix typo "errror" -> "error" --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8810) speeling-error
by sca+openldap＠andreasschulze.de 24 Feb '18

24 Feb '18

Full_Name: Andreas Schulze Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-180224.patch Submission from: (NULL) (2001:470:77b3:50::65) Debian Lintian found a typo in libraries/libldap/os-local.c: "errror" should be "error" Patch attached Andreas

1 0

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> </div><div>today i faced the same problem b= ut because of multiple=C2=A0olcPasswordHash entries. This caused the= =C2=A0userPassword=C2=A0attribute 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= </div><div> </div><div>By the way, restarts didn't help.</div><div><= br></div><div>Regards,</div><div> </div><div>Gena</div><div> </div><d= iv> </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

(ITS#8803) [PATCH] Add -L option for using external locking
by nirsof＠gmail.com 10 Feb '18

10 Feb '18

Full_Name: Nir Soffer Version: master OS: Fedora 27 URL: https://github.com/nirs/lmdb/commit/e9ffc44797f9884590c480d0f160d8f745ee8ff9 Submission from: (NULL) (217.132.180.29) A user may prefer to provide external locking using the MDB_NOLOCK when using the lmdb library. To use the mdb_dump, mdb_load, and mdb_stat with the same locking, we need an option to disable the library internal locking when running these tools. The attached patch file is derived from lmdb Software. All of the modifications to lmdb represented in the following patch(es) were developed by Nir Soffer nirsof(a)gmail.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2018 Nir Soffer Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6268) multi-master sync replication ldap_add error code 68 bug
by quanah＠symas.com 09 Feb '18

09 Feb '18

Hi Barry, I had a few questions to ask in relation to this ITS: a) Can you reproduce this problem with current RE24? and b) Could you provide copies of your shell scripts so I can create a generalized regression test case for this? (And, if this issue is not resolved as of yet, it will help with getting it fixed). Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

It's not that trivial. We recycle cursors because they *might* be reused later. At the point when the txn is done it is unknown whether the cursor will be used in the future.

1 0

Re: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Howard Chu wrote: > Markus Junginger wrote: >>> There was never a bug here. The doc is quite explicit >>> http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 >>> >>> After txn_abort the only valid call on a still-open cursor is >>> cursor_renew, not cursor_close. >> >> However you want to call it, are you open to improve this workflow? >> >> API-wise, it would be so much simpler just to free a cursor after it became >> obsolete. It's counter-intuitive to open a new txn, renew the cursor, close >> the cursor, and abort the txn - just to close a cursor. > > API-wise, it is much simpler to just close the cursor before closing its > transaction, if you have no need to reuse the cursor. To be explicit - a typical workflow, as outlined in the Getting Started guide: Open an env Open a txn inside the env Open a cursor inside the txn When finished: Close cursor inside txn Close txn inside env Close env The only reason the API allows a read cursor to exist outside of its creating read txn is to allow it to be reused in a later read txn. If you're not reusing it then you should just close it in the proper order. -- -- 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#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Markus Junginger wrote: >> There was never a bug here. The doc is quite explicit >> http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 >> >> After txn_abort the only valid call on a still-open cursor is >> cursor_renew, not cursor_close. > > However you want to call it, are you open to improve this workflow? > > API-wise, it would be so much simpler just to free a cursor after it became > obsolete. It's counter-intuitive to open a new txn, renew the cursor, close > the cursor, and abort the txn - just to close a cursor. API-wise, it is much simpler to just close the cursor before closing its transaction, if you have no need to reuse the cursor. -- -- 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#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

> There was never a bug here. The doc is quite explicit > http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 > > After txn_abort the only valid call on a still-open cursor is > cursor_renew, not cursor_close. However you want to call it, are you open to improve this workflow? API-wise, it would be so much simpler just to free a cursor after it became obsolete. It's counter-intuitive to open a new txn, renew the cursor, close the cursor, and abort the txn - just to close a cursor. And without MDB_VL32, plain cursor closing after txn abort seems to work just fine (I did not consider "closing" as "using" when I read the docs). One could say that the inconsistent behavior is a result of the complexity MDB_VL32 introduces. If you don't want to change the current behavior, it would still be nice for future developers to null the obsolete txn ptr in the cursor on txn abort to make the unwanted close call crash always, not just occasionally.

1 0

Re: AW: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

Markus Junginger wrote: > I perfectly see that MDB_VL32 is the superior as a feature. On the other > hand I'm a bit worried that it may hold up LMDB development for use cases > you refer to as obsolete yourself. > > While there are workarounds for this particular bug (which we applied), There was never a bug here. The doc is quite explicit http://www.lmdb.tech/doc/group__mdb.html#ga73a5938ae4c3239ee11efa07eb22b882 After txn_abort the only valid call on a still-open cursor is cursor_renew, not cursor_close. -- -- 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

AW: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

I perfectly see that MDB_VL32 is the superior as a feature. On the other hand I'm a bit worried that it may hold up LMDB development for use cases you refer to as obsolete yourself. While there are workarounds for this particular bug (which we applied), I wouldn't be surprised if MDB_VL32 still needs some stabilization after it will be officially released to get real exposure in the real world. Also, for future changes, the MDB_VL32 "fork" will have to be adjusted as well.

1 0

Re: AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by hyc＠symas.com 09 Feb '18

09 Feb '18

markus(a)greenrobot.de wrote: >> When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit >> into a single mmap. >> [...] > > Long story short: I did not understand MDB_VL32 in the first place. I > thought it would just enable 64 bit sizes. Pointless, if you're still limited to 2GB. It would only eat up 4 extra bytes overhead in every internal integer. >> Ideally, you should quit using obsolete 32bit CPUs. > > Of course. Think about mobile and IoT however: Here, there are still 32 bit > CPUs and it's not uncommon to even make 64 bit ARM CPUs operate in 32 bit > mode to reduce binary size etc. > > I'd like to propose a different approach to 64 bits on 32 bit CPUs; > something like this: > #ifdef MDB_SIZE64 > typedef uint64_t mdb_size_t; > ... > > Why? MDB_VL32 adds complexity and it would take additional coding and > testing efforts to get it production ready. If you had used the API as intended, with txn_reset/renew as I originally suggested, there would be no problem. > > I think MDB_SIZE64 might be a better trade-off. Of course this would only > work with smaller DBs files (< 2GB/4GB). But I don't see a huge scenario for > 32 bit CPUs being able to work with huge files anyway. The reason MDB_VL32 exists at all is because of exactly this - people wanted to use 32 bit CPUs with 64 bit databases. > The main reason I see > to use 64 bits consistently across CPU architecture is binary compatibility. > This is a big thing for Android (shipping apps with prefilled DBs). Also it > enables getting DB files from 32 bit devices and open those on the desktop, > etc. > > What do you think? Bad idea. MDB_VL32 provides *full* compatibility between 32bit and 64bit CPUs *regardless of filesize*. Your suggestion will only cause confusion, as people wonder why their DB dies after reaching 2GB in size. It offers none of the benefits of 64bit capability, while still paying all of the cost in terms of storage overhead. -- -- 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

AW: (ITS#8777) [LMDB] Closing read cursor uses already freed transaction (MDB_VL32)
by markus＠greenrobot.de 09 Feb '18

09 Feb '18

> When using MDB_VL32 to access a 64bit DB on a 32bit CPU, the DB cannot fit > into a single mmap. > [...] Long story short: I did not understand MDB_VL32 in the first place. I thought it would just enable 64 bit sizes. > Ideally, you should quit using obsolete 32bit CPUs. Of course. Think about mobile and IoT however: Here, there are still 32 bit CPUs and it's not uncommon to even make 64 bit ARM CPUs operate in 32 bit mode to reduce binary size etc. I'd like to propose a different approach to 64 bits on 32 bit CPUs; something like this: #ifdef MDB_SIZE64 typedef uint64_t mdb_size_t; ... Why? MDB_VL32 adds complexity and it would take additional coding and testing efforts to get it production ready. I think MDB_SIZE64 might be a better trade-off. Of course this would only work with smaller DBs files (< 2GB/4GB). But I don't see a huge scenario for 32 bit CPUs being able to work with huge files anyway. The main reason I see to use 64 bits consistently across CPU architecture is binary compatibility. This is a big thing for Android (shipping apps with prefilled DBs). Also it enables getting DB files from 32 bit devices and open those on the desktop, etc. What do you think? Thanks, Markus PS.: Here's the full patch (adding MDB_SIZE64), which runs fine at least with our test suite: lmdb.h @@ -187,7 +187,15 @@ # define MDB_FMT_Z "z" /**< printf/scanf format modifier for size_t */ #endif -#ifndef MDB_VL32 +#if defined(MDB_VL32) && defined(MDB_SIZE64) +#error either define MDB_VL32 OR MDB_SIZE64 +#endif +#ifdef MDB_SIZE64 +typedef uint64_t mdb_size_t; +# define MDB_SIZE_MAX SIZE_MAX /**< max #mdb_size_t */ +# define MDB_PRIy(t) PRI##t##64 +# define MDB_SCNy(t) SCN##t##64 +#elif !defined(MDB_VL32)) /** Unsigned type used for mapsize, entry counts and page/transaction IDs. * * It is normally size_t, hence the name. Defining MDB_VL32 makes it

1 0

(ITS#8802) ldappasswd ppolicy
by matsl＠irf.se 08 Feb '18

08 Feb '18

Full_Name: Mats Luspa Version: openldap-2.4.40+dfsg OS: 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) i686 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:6b0:27:cc:2740:e692:a5b1:4b0f) Hello! When you are using ppolicy password changed are recorded in pwdHistory attribute. ldappasswd can't be used due to that. It checks of some reason that pwdHistory not exists before it changes that password. If pwdHistory exists then the ldappaswd can't change the password. Here's the log file: 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace userPassword 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: replace pwdChangedTime 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: add pwdHistory 2018-02-08T09:42:45+01:00 mailserver slapd[725]: bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists 2018-02-08T09:42:45+01:00 mailserver slapd[725]: send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists" /Regards Mats

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs