openldap-bugs April 2018

openldap-bugs@openldap.org

15 participants
28 discussions

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2018