- openldap-bugs - openldap.org

Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by quanah＠symas.com 01 May '18

01 May '18

--On Tuesday, March 14, 2017 6:58 PM +0000 elecharny(a)symas.com wrote: Also fails for olcSpSessionLog (if it wasn't defined when the cn=config db was loaded) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Subject: Re: (ITS#8639) Remove support for LANMAN
by andrew.lawrence＠siemens.com 29 Apr '18

29 Apr '18

Hi, I fixed/implemented this a while ago. I have uploaded a patch to ftp://ftp.= openldap.org/incoming/andrew-lawrence-180429.patch With best regards, Dr Andrew Lawrence Siemens Rail Automation Holdings Limited MO MM R&D UK IXL 17 Langley Park Way Chippenham SN15 1GG, United Kingdom=20 Tel.: +44 1249 441808 Mobile: +44 7921 248744 mailto:andrew.lawrence@siemens.com www.siemens.com/rail-automation 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

1 0

(ITS#8841) Fix for an assertion error in back-meta
by nivanova＠symas.com 25 Apr '18

25 Apr '18

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425-2.patch Submission from: (NULL) (93.152.134.25) This patch contains a fix for the following issue, reported by a customer. When using back-meta, if a network interface towards a target becomes unavailable (e.g disabling a virtual interface), back-meta fails an assert. IPR for this patch: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2018 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#8725) Disable cleanup of extended operations if they are asynchronous
by nivanova＠symas.com 25 Apr '18

25 Apr '18

--=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch --=_ff296a31-6740-4409-806d-173ea531b121 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><div>As part of asyncmeta development, the front-end was made aware if operations were executed by an async back-end and cleanup is to be performed by the backend. This patch adds the same exception of extended operations, which were skipped because asyncmeta did not handle them.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>ftp://ftp.openldap.org/incoming/nadezhda-ivanova-180425.patch<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></body></html> --=_ff296a31-6740-4409-806d-173ea531b121--

1 0

Re: (ITS#6300) Issues with kqueue after fork
by quanah＠symas.com 24 Apr '18

24 Apr '18

--==========C0CB1C4A269A2DB8FD87========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li To: Quanah Gibson-Mount Hi Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========C0CB1C4A269A2DB8FD87========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD (fwd)" Date: Tue, 24 Apr 2018 14:28:57 -0700 From: Quanah Gibson-Mount <quanah(a)symas.com> Reply-To: Quanah Gibson-Mount <quanah(a)symas.com> To: Howard Chu <hyc(a)symas.com> Subject: Re: kqueue in OpenLDAP for FreeBSD (fwd) Message-ID: <49431EE1A7D095C608D778A4(a)[192.168.1.10]> X-Mailer: Mulberry/4.0.9a1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========EF6328C82A1CE901E152==========" --==========EF6328C82A1CE901E152========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline kqueue issues with slapd --Quanah ------------ Forwarded Message ------------ Date: Monday, October 23, 2017 12:43 AM -0700 From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI=20 <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, etc. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd = to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q > > > I've updated my configure to: > > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl = --disable-dependency-tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q > > > And I still have no issues.=C2=A0 I'm unable to get the freebsd version = of > libtool to build shared libraries, so I can't test dynamic modules. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --==========EF6328C82A1CE901E152========== Content-Type: message/rfc822; name="Re: kqueue in OpenLDAP for FreeBSD" Return-Path: delphij(a)delphij.net Received: from 127.37.197.104.bc.googleusercontent.com (LHLO zmcc-5-mta-1.zmailcloud.com) (104.197.37.127) by zmcc-5-mailbox-1.zmailcloud.com with LMTP; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 57E10C0814 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Authentication-Results: zmcc-5-mta-1.zmailcloud.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=delphij.net Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrlpf0yr3bg2 for <qgibson-mount(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (254.215.154.104.bc.googleusercontent.com [104.154.215.254]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTPS id 36497C06D2 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:19 -0500 (CDT) Received: from mailstronghold-1.zmailcloud.com (localhost.localdomain [127.0.0.1]) by mailstronghold-1.zmailcloud.com (8.13.8/8.13.8) with ESMTP id v9N4CeHI010656 for <quanah(a)symas.com>; Mon, 23 Oct 2017 01:43:18 -0500 X-Haraka-RcptSummary: valid=1 invalid=0 unverified=0 relay=0 norelay=0 Received-SPF: Pass (mailstronghold-1.zmailcloud.com: domain of delphij.net designates 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=mailfrom; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received-SPF: None (mailstronghold-1.zmailcloud.com: domain of anubis.delphij.net does not designate 64.62.153.212 as permitted sender) receiver=mailstronghold-1.zmailcloud.com; identity=helo; client-ip=64.62.153.212; helo=anubis.delphij.net; envelope-from=<delphij(a)delphij.net> Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mailstronghold-1.zmailcloud.com (Haraka/2.2.8) with ESMTPS id 44429DF9-9A11-41FD-AF40-A85A1E9CCAE7.1 envelope-from <delphij(a)delphij.net> (version=TLSv1/SSLv3 cipher=AES256-SHA verify=OK); Mon, 23 Oct 2017 01:43:14 -0500 Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:37a:c09f:c4b5:916b:f99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 7315321847; Sun, 22 Oct 2017 23:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1508740990; x=1508755390; bh=lHOLEU7RrRbdsqZiIrERFdjtGcmjK0d4J65y4NciNAE=; h=Cc:Subject:To:References:From:Date:In-Reply-To; b=pSf21voW+1hi95e1Gk7n0Etfo4WpoqUlF4m7Ukgp6+Sw1OreGQEjQPiBMq0Wo6htG P/+uPZswNtPxpr/6yGE9Fsrxku8Bygk6Qv/o3pR9rRe0bKhvrh+jqAcM0KvcjgG9cV geciuENhFuihiQm9Jh/4383kqyrcrgnufON8XY4Q= Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Subject: Re: kqueue in OpenLDAP for FreeBSD To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> From: Xin Li <delphij(a)delphij.net> Date: Sun, 22 Oct 2017 23:43:05 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ" X-Haraka-Syntax: mail_case=upper mail_leading_spaces=N mail_trailing_spaces=N mail_missing_brackets=N rcpt_case=upper rcpt_leading_spaces=N rcpt_missing_brackets=N rcpt_trailing_spaces=N X-Haraka-GeoIP: US X-Haraka-GeoIP-Received: 64.62.153.212:US X-Haraka-rDNS: anubis.delphij.net X-Haraka-FCrDNS: anubis.delphij.net X-Haraka-HostID: delphij.net X-Haraka-SenderAuth: 64.62.153.212 delphij.net X-Haraka-Domain-Info: domain="delphij.net" last_update=176 primary_ns="ns-us.delphij.net" serial=2017043060 refresh=7200 retry=3600 expiration=604800 minimum=14400 flags="" X-Haraka-Watermark: references:WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!@mailstronghold-3.zmailcloud.com References: <1EEAC653239F6692643DB632(a)192.168.1.30> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Message-Id: <WM!ff18dbc4fd0ca98069f4da171165aabfe0351a19a07c5c098b191f5850c1c079bf8b820779722c14189597ab2ab2028a!(a)mailstronghold-1.zmailcloud.com> X-FSL-MailScanner-Information: Please contact postmaster(a)zmailcloud.com for more information X-FSL-MailScanner-ID: v9N4CeHI010656 X-FSL-MailScanner: Found to be clean X-Dirty-Status: X-FSL-MailScanner-From: delphij(a)delphij.net This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: multipart/mixed; boundary="SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl"; protected-headers="v1" From: Xin Li <delphij(a)delphij.net> To: Quanah Gibson-Mount <quanah(a)symas.com>, Xin LI <delphij(a)gmail.com> Cc: d(a)delphij.net, Pietro Cerutti <gahr(a)gahr.ch>, Xin LI <delphij(a)freebsd.org> Message-ID: <cff1e448-975f-f832-4ced-7c68108abf49(a)delphij.net> Subject: Re: kqueue in OpenLDAP for FreeBSD References: <1EEAC653239F6692643DB632(a)192.168.1.30> <WM!652ba1f610b07a3646a24508aa83d70e7fbfbbbf4a02ab2f4f5c75bea4ea7433084f5a08cbd2551d01ebcc1be8bfada2!(a)mailstronghold-3.zmailcloud.com> <806290B685E4C0A58E186335(a)192.168.1.30> <a77bd491-68e1-d071-90d1-f081685137cd(a)delphij.net> <WM!9301149f169acc8af0f3fbefd6be96ab8874fd401aaf6373e9390d058b5fc3a788bd3202b6db71ad2dcfda2aec5e5b59!(a)mailstronghold-3.zmailcloud.com> <058DB23288D5009E6DBB5BCD(a)192.168.1.30> <CAGMYy3shfuAS85XowEVaFcnOUKpU2PDMqm8+PWzch93f0j_bXg(a)mail.gmail.com> <WM!a464e9245a6039036609ea76ee2d9e4d48947932ced97d50fe93b3951122d1549508f510bddbbc94dc5a58711bef7c3a!(a)mailstronghold-2.zmailcloud.com> <6C1DC7E9BE41FA3CD93838AC(a)192.168.1.30> <CAGMYy3tWs52_RvSjQHtg17D1vOE9BM4YWEpO9k1Oc82L+0fJsA(a)mail.gmail.com> <WM!989b88c2339699eecc479074ef90267785f2f7857ca6a68544f30ecbc534e2146b4db747de2aede7c8f671fd55da9d58!(a)mailstronghold-3.zmailcloud.com> <62041328E5AFD06BBFCFDF96(a)[192.168.1.30]> <D8979E6E67B623588F99E3B7(a)[192.168.1.30]> <5b003a32-e2cc-0ae0-1dc9-1f994b4b06a4(a)delphij.net> <WM!a1b49a63e95c1d3f455af9c2777883d03dd1e46303f3c7e5270170ec581ec4658216e91e73f74b5dec589501ad7b5d03!(a)mailstronghold-3.zmailcloud.com> <A3DFF2D02CD1C134AAC9771D(a)[192.168.1.30]> <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> In-Reply-To: <77291973D4E980CDD2C6B12D(a)[192.168.1.30]> --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl Content-Type: multipart/mixed; boundary="------------617F49AD045D5D9CF20DDEA9" Content-Language: en-US This is a multi-part message in MIME format. --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Quanah, I finally got some time to twiddle with OpenLDAP (again). It looks like the EBADF is expected, because fork(2) says: =E2=80=A2 The child process has its own copy of the parent's= descriptors, except for descriptors returned by kqueue(2), which are not inherited from the parent process. And slapd does have a fork() after the initial kqueue(), which rendered it invalid. The kqueue() is part of SLAP_SOCK_INIT(), which is part of slapd_daemon_init(). Then, after that, fork() happen in lutil_detach(), and doing this hack would (incorrectly) make slapd to start: diff --git a/libraries/liblutil/detach.c b/libraries/liblutil/detach.c index c6464c038..f47d36548 100644 --- a/libraries/liblutil/detach.c +++ b/libraries/liblutil/detach.c @@ -73,7 +73,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_THR pid =3D fork1(); #else - pid =3D fork(); + pid =3D rfork(RFPROC); #endif switch ( pid ) { It is incorrect because the code in slapd/main.c seems to expect the child to write a "1" to it before exiting with EXIT_SUCCESS() and obviously if the two processes shares the same file table, the parent would consider the start was failed because read() would fail. I think the right fix would be to move the lutil_detach() to before slapd_daemon_init(), see attachment, but it seems that some code after the initial daemon initialization is still trying to output to stderr, et= c. What do you think? Cheers, On 10/20/17 09:00, Quanah Gibson-Mount wrote: > --On Friday, October 20, 2017 8:15 AM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: >=20 >> Thanks, I'll play around with the build some.=C2=A0 I'm limiting slapd= to as >> minimal a build as possible with my configure: >> >> ./configure --without-tls --without-cyrus-sasl --enable-ldap >> --enable-meta --enable-accesslog --enable-ppolicy --enable-rewrite >> --enable-rwm --prefix=3D/tmp/q >=20 >=20 > I've updated my configure to: >=20 > CFLAGS=3D"-O2 -pipe=C2=A0 -fstack-protector -DLDAP_DEPRECATED > -fno-strict-aliasing" \ > ./configure \ > --with-threads=3Dposix=C2=A0 --with-tls=3Dopenssl --disable-dependency-= tracking \ > --enable-dynamic --without-cyrus-sasl \ > --localstatedir=3D/var/db=C2=A0 --enable-crypt=C2=A0 --enable-ldap \ > --enable-meta=C2=A0 --enable-rewrite=C2=A0 --enable-null \ > --enable-monitor --disable-seqmod --enable-syncprov \ > --enable-mdb --without-fetch \ > --prefix=3D/tmp/q >=20 >=20 > And I still have no issues.=C2=A0 I'm unable to get the freebsd version= of > libtool to build shared libraries, so I can't test dynamic modules. >=20 > --Quanah >=20 >=20 > --=20 >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >=20 --------------617F49AD045D5D9CF20DDEA9 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="slapd-workaround.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="slapd-workaround.patch" ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvbWFpbi5jIGIvc2VydmVycy9zbGFwZC9tYWlu LmMKaW5kZXggMGEwNTNjM2VlLi4xOGQ4NDBjNWEgMTAwNjQ0Ci0tLSBhL3NlcnZlcnMvc2xh cGQvbWFpbi5jCisrKyBiL3NlcnZlcnMvc2xhcGQvbWFpbi5jCkBAIC02OTIsNiArNjkyLDkg QEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJYmVyX3NldF9vcHRpb24oTlVMTCwgTEJFUl9PUFRf REVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGFwX3NldF9vcHRpb24oTlVMTCwgTERB UF9PUFRfREVCVUdfTEVWRUwsICZzbGFwX2RlYnVnKTsKIAlsZGlmX2RlYnVnID0gc2xhcF9k ZWJ1ZzsKKwlpZiAoIGNoZWNrICE9IENIRUNLX05PTkUgKSB7CisJCW5vX2RldGFjaCA9IDE7 CisJfQogCiAJaWYgKCB2ZXJzaW9uICkgewogCQlmcHJpbnRmKCBzdGRlcnIsICIlc1xuIiwg VmVyc2lvbnN0ciApOwpAQCAtNzM5LDYgKzc0MiwyOSBAQCB1bmhhbmRsZWRfb3B0aW9uOjsK IAlnbG9iYWxfaG9zdCA9IGxkYXBfcHZ0X2dldF9mcWRuKCBOVUxMICk7CiAJYmVyX3N0cjJi diggZ2xvYmFsX2hvc3QsIDAsIDAsICZnbG9iYWxfaG9zdF9idiApOwogCisjaWZuZGVmIEhB VkVfV0lOU09DSworCWlmICggIW5vX2RldGFjaCApIHsKKwkJaWYgKCBsdXRpbF9wYWlyKCB3 YWl0ZmRzICkgPCAwICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfQU5ZLAorCQkJCSJtYWlu OiBsdXRpbF9wYWlyIGZhaWxlZDogJWRcbiIsCisJCQkJMCwgMCwgMCApOworCQkJcmMgPSAx OworCQkJZ290byBkZXN0cm95OworCQl9CisJCXBpZCA9IGx1dGlsX2RldGFjaCggbm9fZGV0 YWNoLCAwICk7CisJCWlmICggcGlkICkgeworCQkJY2hhciBidWZbNF07CisJCQlyYyA9IEVY SVRfU1VDQ0VTUzsKKwkJCWNsb3NlKCB3YWl0ZmRzWzFdICk7CisJCQlpZiAoIHJlYWQoIHdh aXRmZHNbMF0sIGJ1ZiwgMSApICE9IDEgKQorCQkJCXJjID0gRVhJVF9GQUlMVVJFOworCQkJ X2V4aXQoIHJjICk7CisJCX0gZWxzZSB7CisJCQljbG9zZSggd2FpdGZkc1swXSApOworCQl9 CisJfQorI2VuZGlmIC8qIEhBVkVfV0lOU09DSyAqLworCiAJaWYoIGNoZWNrID09IENIRUNL X05PTkUgJiYgc2xhcGRfZGFlbW9uX2luaXQoIHVybHMgKSAhPSAwICkgewogCQlyYyA9IDE7 CiAJCVNFUlZJQ0VfRVhJVCggRVJST1JfU0VSVklDRV9TUEVDSUZJQ19FUlJPUiwgMTYgKTsK QEAgLTkxMSwyOSArOTM3LDYgQEAgdW5oYW5kbGVkX29wdGlvbjo7CiAJKHZvaWQpIFNJR05B TCggU0lHQlJFQUssIHNsYXBfc2lnX3NodXRkb3duICk7CiAjZW5kaWYKIAotI2lmbmRlZiBI QVZFX1dJTlNPQ0sKLQlpZiAoICFub19kZXRhY2ggKSB7Ci0JCWlmICggbHV0aWxfcGFpcigg d2FpdGZkcyApIDwgMCApIHsKLQkJCURlYnVnKCBMREFQX0RFQlVHX0FOWSwKLQkJCQkibWFp bjogbHV0aWxfcGFpciBmYWlsZWQ6ICVkXG4iLAotCQkJCTAsIDAsIDAgKTsKLQkJCXJjID0g MTsKLQkJCWdvdG8gZGVzdHJveTsKLQkJfQotCQlwaWQgPSBsdXRpbF9kZXRhY2goIG5vX2Rl dGFjaCwgMCApOwotCQlpZiAoIHBpZCApIHsKLQkJCWNoYXIgYnVmWzRdOwotCQkJcmMgPSBF WElUX1NVQ0NFU1M7Ci0JCQljbG9zZSggd2FpdGZkc1sxXSApOwotCQkJaWYgKCByZWFkKCB3 YWl0ZmRzWzBdLCBidWYsIDEgKSAhPSAxICkKLQkJCQlyYyA9IEVYSVRfRkFJTFVSRTsKLQkJ CV9leGl0KCByYyApOwotCQl9IGVsc2UgewotCQkJY2xvc2UoIHdhaXRmZHNbMF0gKTsKLQkJ fQotCX0KLSNlbmRpZiAvKiBIQVZFX1dJTlNPQ0sgKi8KLQogI2lmZGVmIENTUklNQUxMT0MK IAltYWxfbGVha3RyYWNlKDEpOwogI2VuZGlmCg== --------------617F49AD045D5D9CF20DDEA9-- --SvfB4mi1pAhURkJI3rrmDUDBPqtcBdtKl-- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ7Y99AAoJEJW2GBstM+nstpMP/0zXWEdlSWycZyYU8ukkLUju Bd+3oVJyhwuVFhVHp4mts+nApF6+yPzMTlhT930cyD+LJ5TLrfaR9bVoVkix0LMk YX7KF7jHWZU/B7+o4VR1l/oMFoRr4qSXQ+hiFgiDZg+id8s9CxnndzmbWK+vgRSp j2ynuh7aQbLBkkao8mfHG/UbDvTvre8BVw9WF/vidwieDGOITo28088ZbX8XgjTO 9e7WFw+ftnFKkv63o/GDOCo+1zFm7n+F7gv4DmZYrt3ZdHCcSRkHMXPltf/4/IRX pFve1h24mPsq0sqit1wsDj2k3f3cJRN4rEShIBfiZm1y4rmCFC8ogDyllBdEbqRd RoN2ol6nh2k38qR4WAHhMFRyCUgUnqYevC7L+AlUAXiweSgzUKfVZt0bpiVnZPDT NiuAX1fBBQIySWzF/iM4d3VPIZdPmcme72kRCLcpbViTW+u4/n+RJEdKl4QRSSrw 5DzVwZDLgl16Ch+YLUYoaSyyk8strbe62owDf6GOb4Pnwy3wBf5o1oIsn/tcu6mh JA2IIVQ9mS3rwDgnL9O7GxrAmWFgpzZmBEC9mYbOToW4EMzDMBj4M7cwrLAVpae7 8KDX5xWX8swr56W8/8PQayLf574lPBhx9QZorKnoIzycHXCI/NkXbW9NBJTr/LLk 0etBpNlk83eCTvtejbbR =dl/v -----END PGP SIGNATURE----- --5jhqIfAmTWbgiqGDq2LUIR42Ndk8MNrPJ-- --==========EF6328C82A1CE901E152==========-- --==========C0CB1C4A269A2DB8FD87==========--

1 0

Re: (ITS#8840) domainScope control is not properly implemented
by quanah＠symas.com 23 Apr '18

23 Apr '18

--On Friday, April 20, 2018 3:28 PM +0000 elecharny(a)symas.com wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.123.98.139) > > > There has been a change back in 2011 in the controls.c code : > > https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd3 > 556f941a#diff-8237ff8d4da3d46fed54a93482b3a908 This is not a valid link, as it points to a private repository. In the future, please provide a valid reference. The commit at issue is: commit f810e6ed417939ed69b388ad7fb0c696e185f593 Author: Kurt Zeilenga <kurt(a)openldap.org> Date: Fri Apr 20 22:32:58 2007 +0000 Distinguish absent control value from empty control value. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8840) domainScope control is not properly implemented
by elecharny＠symas.com 20 Apr '18

20 Apr '18

Full_Name: Emmanuel Lecharny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.123.98.139) There has been a change back in 2011 in the controls.c code : https://github.com/Symas/openldap/commit/4e32148ac59ba6b4f3acc79a3b782cd355… Line 1460 was : if ( ctrl->ldctl_value.bv_len ) { and was transformed to line 1516 : if ( BER_BVISNULL( &ctrl->ldctl_value )) { when it was expected to be : if ( !BER_BVISNULL( &ctrl->ldctl_value )) { as this control is not expecting any value. The consequence is that using this control in ldapsearch leads to an error being generated : "domainScope control value not empty"

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Ok, thanks for your prompt action=2E I confirm it's fixed ;) On April 18, 2018 9:52:08 PM GMT+09:00, Howard Chu <hyc@symas=2Ecom> wrote= : >arekkusu@r42=2Ech wrote: >> Full_Name: Alexandre Rosenberg >> Version: - >> OS: - >> URL: ftp://ftp=2Eopenldap=2Eorg/incoming/ >> Submission from: (NULL) (125=2E30=2E28=2E204) >>=20 >>=20 >> Hello, >>=20 >> TLS certificate for CN=3Dwww=2Eopenldap=2Eorg and many alternative subj= ect >name has >> expired=2E (April 17, 2018, 5:01:56 PM GMT) >>=20 >> I noticed you are using Let's Encrypt=2E I suggest setting up some sort >of >> reminder and/or automated renewal=2E > >Yes, the cron job for auto renewal failed=2E It's updated now=2E >>=20 >> Best, >> Alex >>=20 >> ------------- >>=20 >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: >> 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C =3D US, O =3D Let's Encrypt, CN =3D Let's Encrypt >Authority X3 >> Validity >> Not Before: Jan 17 17:01:56 2018 GMT >> Not After : Apr 17 17:01:56 2018 GMT >> Subject: CN =3D www=2Eopenldap=2Eorg >> (=2E=2E=2E) >> =20 >>=20 >>=20

1 0

(ITS#8839) never use md5 and/or sha1, use sha512, file signing
by openldap＠openldap.org 18 Apr '18

18 Apr '18

Full_Name: openldap user Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.87.231.80) use a 4096-bit rsa key for signing the release files

1 0

Re: (ITS#8838) TLS cert for www.openldap.org expired
by hyc＠symas.com 18 Apr '18

18 Apr '18

arekkusu(a)r42.ch wrote: > Full_Name: Alexandre Rosenberg > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (125.30.28.204) > > > Hello, > > TLS certificate for CN=www.openldap.org and many alternative subject name has > expired. (April 17, 2018, 5:01:56 PM GMT) > > I noticed you are using Let's Encrypt. I suggest setting up some sort of > reminder and/or automated renewal. Yes, the cron job for auto renewal failed. It's updated now. > > Best, > Alex > > ------------- > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 > Validity > Not Before: Jan 17 17:01:56 2018 GMT > Not After : Apr 17 17:01:56 2018 GMT > Subject: CN = www.openldap.org > (...) > > > -- -- 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#8838) TLS cert for www.openldap.org expired
by arekkusu＠r42.ch 18 Apr '18

18 Apr '18

Full_Name: Alexandre Rosenberg Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.28.204) Hello, TLS certificate for CN=www.openldap.org and many alternative subject name has expired. (April 17, 2018, 5:01:56 PM GMT) I noticed you are using Let's Encrypt. I suggest setting up some sort of reminder and/or automated renewal. Best, Alex ------------- Certificate: Data: Version: 3 (0x2) Serial Number: 03:d3:9f:63:93:c2:18:aa:89:b2:32:43:13:18:72:ba:81:00 Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Validity Not Before: Jan 17 17:01:56 2018 GMT Not After : Apr 17 17:01:56 2018 GMT Subject: CN = www.openldap.org (...)

1 0

(ITS#8837) fix pw-pbkdf2 man-mage name to get it installed
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although pw-pbkdf2 is not an overlay but a mere module, the existing man page for this module is named slapo-pw-pbkdf2.5. On the other hand, pw-pbkdf2's Makefile correctly mentions the manual page as slapd-pw-pbkdf2.5. Together this results in pw-pbpkdf2's manual page not getting installed despite being available. To fix the issue, please rename contrib/slapd-modules/passwd/pbkdf2/slapo-pw-pbkdf2.5 to contrib/slapd-modules/passwd/pbkdf2/slapd-pw-pbkdf2.5 Thanks in advance Peter

1 0

(ITS#8836) include TOTP into future releases
by peter＠adpm.de 13 Apr '18

13 Apr '18

Full_Name: Peter Marschall Version: 2.4.46 OS: Linux URL: Submission from: (NULL) (217.249.216.145) Hi, although contrib/slapd-modules/passwd/totp/ is part of OpenLDAP's git repository, it is not published as part of recent OpenLDAP releases. Please include contrib/slapd-modules/passwd/totp/ and its contents into future releases of OpenLDAP. Thanks in advance Peter

1 0

(ITS#8835) update admin guide to use "openssl rehash" instead of c_rehash
by ryan＠openldap.org 07 Apr '18

07 Apr '18

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan >From https://bugs.debian.org/895091 - > This package is using the c_rehash command which is part of the > openssl package. The c_rehash script is considered by upstream as a > fallback script and will disappear at some point. The recommended way > is to use the "openssl rehash" command instead which appeared in > 1.1.0. Please make sure that this package does not use the c_rehash > command anymore. The "will disappear at some point" wording seems to come from this issue comment: https://github.com/openssl/openssl/issues/5772#issuecomment-376881454 The TLS chapter in the admin guide should be updated to suggest "openssl rehash" instead of c_rehash.

1 0

Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by h.b.furuseth＠usit.uio.no 07 Apr '18

07 Apr '18

On 20/03/2018 19:58, hyc(a)symas.com wrote: > We once discussed padding odd-length keys to make sure the data was still > word-aligned. Maybe should do that in LMDB 1.0. This particular crash is now > fixed in mdb.master. I've left other derefs of *fp alone for the moment but > may need to revisit that later; older ARM and SPARC would probably choke on them. Yes. Also, as this bug demonstrates, compilers will keep finding new ways to break over-aligned pointers even on x86. The way to make sure a compiler cannot deduce that a sub-page is 8- or 4- byte aligned, is to never create such over-aligned pointer values. I.e. pass something like struct MDB_pageinfo instead of MDB_page to anything which may receive a 2-byte-aligned sub-page: typedef struct MDB_pageinfo { uint16_t mi_pad, mi_flags; indx_t mi_lower, mi_upper; # define MI_OVPAGES(mi) (((unsigned)(mi)->mi_upper<<16) + (mi)->mi_lower) } MDB_pageinfo; typedef struct MDB_page { pgno_t mp_pgno; MDB_pageinfo mp_info; indx_t mp_ptrs[1]; } MDB_page;

1 0

Re: (ITS#8832) Fix build with LibreSSL 2.7
by brnrd＠freebsd.org 02 Apr '18

02 Apr '18

--=_32c40086ddbc26d4227512da6e5a0660 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2018-04-02 19:40, openldap-its(a)openldap.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** For completeness, adding the full patch file. That naming of patches by format-patch is silly... I'm generating a lot of them and all get the same name... --=_32c40086ddbc26d4227512da6e5a0660 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=0001-Fix-build-with-LibreSSL-2.7.patch Content-Disposition: attachment; filename=0001-Fix-build-with-LibreSSL-2.7.patch; size=2716 RnJvbSBlOGI4ZGE5ZTQyODQxMzFkZjNhN2VlNjI3MTkzNmU0YWE1YWM1OWNjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCZXJuYXJkIFNwaWwgPGJybnJkQEZyZWVCU0Qub3JnPgpEYXRl OiBNb24sIDIgQXByIDIwMTggMTk6MzE6MDEgKzAyMDAKU3ViamVjdDogW1BBVENIXSBGaXggYnVp bGQgd2l0aCBMaWJyZVNTTCAyLjcKCkxpYnJlU1NMIDIuNyBpbXBsZW1lbnRzIE9wZW5TU0wgMS4x IEFQSQoKU2lnbmVkLW9mZi1ieTogQmVybmFyZCBTcGlsIDxicm5yZEBGcmVlQlNELm9yZz4KLS0t CiBsaWJyYXJpZXMvbGlibGRhcC90bHNfby5jIHwgMTIgKysrKysrLS0tLS0tCiAxIGZpbGUgY2hh bmdlZCwgNiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpYnJh cmllcy9saWJsZGFwL3Rsc19vLmMgYi9saWJyYXJpZXMvbGlibGRhcC90bHNfby5jCmluZGV4IDAx MGYzMTFkNy4uZDU5OTY3MmVlIDEwMDY0NAotLS0gYS9saWJyYXJpZXMvbGlibGRhcC90bHNfby5j CisrKyBiL2xpYnJhcmllcy9saWJsZGFwL3Rsc19vLmMKQEAgLTQ3LDcgKzQ3LDcgQEAKICNpbmNs dWRlIDxzc2wuaD4KICNlbmRpZgogCi0jaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA+PSAweDEw MTAwMDAwCisjaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA+PSAweDEwMTAwMDAwICYmICEoZGVm aW5lZChMSUJSRVNTTF9WRVJTSU9OX05VTUJFUikgJiYgTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIg PCAweDIwNzAwMDAwKQogI2RlZmluZSBBU04xX1NUUklOR19kYXRhKHgpCUFTTjFfU1RSSU5HX2dl dDBfZGF0YSh4KQogI2VuZGlmCiAKQEAgLTIwNSw3ICsyMDUsNyBAQCB0bHNvX2luaXQoIHZvaWQg KQogCSh2b2lkKSB0bHNvX3NlZWRfUFJORyggbG8tPmxkb190bHNfcmFuZGZpbGUgKTsKICNlbmRp ZgogCi0jaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MTAxMDAwMDAKKyNpZiBPUEVOU1NM X1ZFUlNJT05fTlVNQkVSIDwgMHgxMDEwMDAwMCB8fCAoZGVmaW5lZChMSUJSRVNTTF9WRVJTSU9O X05VTUJFUikgJiYgTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIgPCAweDIwNzAwMDAwKQogCVNTTF9s b2FkX2Vycm9yX3N0cmluZ3MoKTsKIAlTU0xfbGlicmFyeV9pbml0KCk7CiAJT3BlblNTTF9hZGRf YWxsX2RpZ2VzdHMoKTsKQEAgLTI1Nyw3ICsyNTcsNyBAQCBzdGF0aWMgdm9pZAogdGxzb19jdHhf cmVmKCB0bHNfY3R4ICpjdHggKQogewogCXRsc29fY3R4ICpjID0gKHRsc29fY3R4ICopY3R4Owot I2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEwMTAwMDAwCisjaWYgT1BFTlNTTF9WRVJT SU9OX05VTUJFUiA8IDB4MTAxMDAwMDAgfHwgKGRlZmluZWQoTElCUkVTU0xfVkVSU0lPTl9OVU1C RVIpICYmIExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSIDwgMHgyMDcwMDAwMCkKICNkZWZpbmUJU1NM X0NUWF91cF9yZWYoY3R4KQlDUllQVE9fYWRkKCAmKGN0eC0+cmVmZXJlbmNlcyksIDEsIENSWVBU T19MT0NLX1NTTF9DVFggKQogI2VuZGlmCiAJU1NMX0NUWF91cF9yZWYoIGMgKTsKQEAgLTU4Nyw3 ICs1ODcsNyBAQCB0bHNvX3Nlc3Npb25fbXlfZG4oIHRsc19zZXNzaW9uICpzZXNzLCBzdHJ1Y3Qg YmVydmFsICpkZXJfZG4gKQogCWlmICgheCkgcmV0dXJuIExEQVBfSU5WQUxJRF9DUkVERU5USUFM UzsKIAkKIAl4biA9IFg1MDlfZ2V0X3N1YmplY3RfbmFtZSh4KTsKLSNpZiBPUEVOU1NMX1ZFUlNJ T05fTlVNQkVSIDwgMHgxMDEwMDAwMAorI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEw MTAwMDAwIHx8IChkZWZpbmVkKExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSKSAmJiBMSUJSRVNTTF9W RVJTSU9OX05VTUJFUiA8IDB4MjA3MDAwMDApCiAJZGVyX2RuLT5idl9sZW4gPSBpMmRfWDUwOV9O QU1FKCB4biwgTlVMTCApOwogCWRlcl9kbi0+YnZfdmFsID0geG4tPmJ5dGVzLT5kYXRhOwogI2Vs c2UKQEAgLTYyMyw3ICs2MjMsNyBAQCB0bHNvX3Nlc3Npb25fcGVlcl9kbiggdGxzX3Nlc3Npb24g KnNlc3MsIHN0cnVjdCBiZXJ2YWwgKmRlcl9kbiApCiAJCXJldHVybiBMREFQX0lOVkFMSURfQ1JF REVOVElBTFM7CiAKIAl4biA9IFg1MDlfZ2V0X3N1YmplY3RfbmFtZSh4KTsKLSNpZiBPUEVOU1NM X1ZFUlNJT05fTlVNQkVSIDwgMHgxMDEwMDAwMAorI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIg PCAweDEwMTAwMDAwIHx8IChkZWZpbmVkKExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSKSAmJiBMSUJS RVNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MjA3MDAwMDApCiAJZGVyX2RuLT5idl9sZW4gPSBpMmRf WDUwOV9OQU1FKCB4biwgTlVMTCApOwogCWRlcl9kbi0+YnZfdmFsID0geG4tPmJ5dGVzLT5kYXRh OwogI2Vsc2UKQEAgLTk1OSw3ICs5NTksNyBAQCBzdHJ1Y3QgdGxzX2RhdGEgewogCVNvY2tidWZf SU9fRGVzYwkJKnNiaW9kOwogfTsKIAotI2lmIE9QRU5TU0xfVkVSU0lPTl9OVU1CRVIgPCAweDEw MTAwMDAwCisjaWYgT1BFTlNTTF9WRVJTSU9OX05VTUJFUiA8IDB4MTAxMDAwMDAgfHwgKGRlZmlu ZWQoTElCUkVTU0xfVkVSU0lPTl9OVU1CRVIpICYmIExJQlJFU1NMX1ZFUlNJT05fTlVNQkVSIDwg MHgyMDcwMDAwMCkKICNkZWZpbmUgQklPX3NldF9pbml0KGIsIHgpCWItPmluaXQgPSB4CiAjZGVm aW5lIEJJT19zZXRfZGF0YShiLCB4KQliLT5wdHIgPSB4CiAjZGVmaW5lIEJJT19jbGVhcl9mbGFn cyhiLCB4KQliLT5mbGFncyAmPSB+KHgpCi0tIAoyLjE2LjMKCg== --=_32c40086ddbc26d4227512da6e5a0660--

1 0

(ITS#8832) Fix build with LibreSSL 2.7
by brnrd＠FreeBSD.org 02 Apr '18

02 Apr '18

Full_Name: Bernard Spil Version: 2.4.45 OS: FreeBSD 11.1-p8 amd64 URL: https://brnrd.eu/bsd/0001-Fix-build-with-LibreSSL-2.7.patch Submission from: (NULL) (193.164.217.85) LibreSSL 2.7 adds OpenSSL 1.1 API which currently leads to conflicts on method names. In 6 months time, support for LibreSSL 2.6 will stop, which would remove all the LIBRESSL_VERSION_NUMBER checks. With kind regards, Bernard

1 0

Re: (ITS#8831) Database flags reset in mdb_load
by hyc＠symas.com 02 Apr '18

02 Apr '18

gnoe(a)symas.com wrote: > Full_Name: Gregory Noe > Version: 2.4.46 > OS: All > URL: ftp://ftp.openldap.org/incoming/mdb_load-dbflag-patch.c > Submission from: (NULL) (63.142.209.94) > > > The flags variable set by the readhdr function in mdb_load is getting set to 0 > before the mdb database is opened for writing. The submitted patch fixes the > issue. > > > --- > Symas Corporation hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > --- Thanks for the report. A slightly different patch was used. Fixed now in mdb.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

(ITS#8831) Database flags reset in mdb_load
by gnoe＠symas.com 02 Apr '18

02 Apr '18

Full_Name: Gregory Noe Version: 2.4.46 OS: All URL: ftp://ftp.openldap.org/incoming/mdb_load-dbflag-patch.c Submission from: (NULL) (63.142.209.94) The flags variable set by the readhdr function in mdb_load is getting set to 0 before the mdb database is opened for writing. The submitted patch fixes the issue. --- Symas Corporation hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. ---

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 02 Apr '18

02 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 12:37 PM, Howard Chu wrote: >> vcunat(a)gmail.com wrote: >>> On 04/01/2018 12:12 PM, Howard Chu wrote: >>>> The rules you patched are only for generating gcov-compatible binari= es. >>>> They aren't even invoked by "make test" so I don't see why this has = any >>>> impact on your build at all. >>>> >>> >>> The build looks like this: >>> ... >>> running tests >>> ar rs liblmdb.a mdb.o midl.o >>> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cas= t >>> -Wuninitialized=C3=82 =C3=82 mdb_stat.o liblmdb.a=C3=82 -o mdb_stat >>> make: gcc: Command not found >> >> What's the actual command line you used to invoke this? >=20 > It should be basically `make` before that part and `make test` in the > "running tests" part. Some build flags were passed, too. >=20 > Hmm, weird, I can't see why make decided to do this, and it doesn't > happen with Linux+clang locally (I have no direct access to osx now). > Maybe I'm just tired ATM. Possibly the full failed build log will shed > light on this? > https://logs.nix.ci/?key=3Dnixos/nixpkgs.38289&attempt_id=3De3767f8e-8c= 1e-4404-93b1-d23d9fe429ee >=20 > If you can't see why, I'll try to revisit this weirdness to avoid > potential surprises in future. The log doesn't show the actual command invocations. Most likely your "ma= ke=20 test" isn't setting CC=3Dgcc. It's probably also doing something else wei= rd=20 since it's building liblmdb.a twice. Regardless, there is no bug in the L= MDB=20 Makefile, your build invocations are broken. Closing this ITS. --=20 -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 12:37 PM, Howard Chu wrote: > vcunat(a)gmail.com wrote: >> On 04/01/2018 12:12 PM, Howard Chu wrote: >>> The rules you patched are only for generating gcov-compatible binaries. >>> They aren't even invoked by "make test" so I don't see why this has any >>> impact on your build at all. >>> >> >> The build looks like this: >> ... >> running tests >> ar rs liblmdb.a mdb.o midl.o >> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >> -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat >> make: gcc: Command not found > > What's the actual command line you used to invoke this? It should be basically `make` before that part and `make test` in the "running tests" part. Some build flags were passed, too. Hmm, weird, I can't see why make decided to do this, and it doesn't happen with Linux+clang locally (I have no direct access to osx now). Maybe I'm just tired ATM. Possibly the full failed build log will shed light on this? https://logs.nix.ci/?key=nixos/nixpkgs.38289&attempt_id=e3767f8e-8c1e-4404-… If you can't see why, I'll try to revisit this weirdness to avoid potential surprises in future.

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 01 Apr '18

01 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 12:12 PM, Howard Chu wrote: >> The rules you patched are only for generating gcov-compatible binaries. >> They aren't even invoked by "make test" so I don't see why this has any >> impact on your build at all. >> > > The build looks like this: > ... > running tests > ar rs liblmdb.a mdb.o midl.o > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat > make: gcc: Command not found What's the actual command line you used to invoke this? -- -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 12:12 PM, Howard Chu wrote: > The rules you patched are only for generating gcov-compatible binaries. > They aren't even invoked by "make test" so I don't see why this has any > impact on your build at all. > The build looks like this: ... running tests ar rs liblmdb.a mdb.o midl.o gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat make: gcc: Command not found

1 0

Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com 01 Apr '18

01 Apr '18

vcunat(a)gmail.com wrote: > On 04/01/2018 11:53 AM, Howard Chu wrote: >> The coverage flags have only been tested with gcc. What compiler are you >> using that also provides code coverage with these flags? > > This is clang on osx, kind of. > > NixOS.org is packaging lmdb for various "platforms", including osx. And > we run `make test` to be more confident about the result. That's what > now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed > the build (though I didn't really check anything; I don't really have > any osx machine myself). > > My experience in general is that clang tries to be compatible with gcc. The rules you patched are only for generating gcov-compatible binaries. They aren't even invoked by "make test" so I don't see why this has any impact on your build at all. -- -- 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#8830) build hardcodes gcc
by vcunat＠gmail.com 01 Apr '18

01 Apr '18

On 04/01/2018 11:53 AM, Howard Chu wrote: > The coverage flags have only been tested with gcc. What compiler are you > using that also provides code coverage with these flags? This is clang on osx, kind of. NixOS.org is packaging lmdb for various "platforms", including osx. And we run `make test` to be more confident about the result. That's what now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed the build (though I didn't really check anything; I don't really have any osx machine myself). My experience in general is that clang tries to be compatible with gcc.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs