(ITS#8837) fix pw-pbkdf2 man-mage name to get it installed
by peter＠adpm.de
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
4 years, 11 months
(ITS#8836) include TOTP into future releases
by peter＠adpm.de
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
4 years, 11 months
(ITS#8835) update admin guide to use "openssl rehash" instead of c_rehash
by ryan＠openldap.org
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.
4 years, 11 months
Re: (ITS#8819) LMDB seg fault with MDB_DUPSORT on -O3
by h.b.furuseth＠usit.uio.no
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;
4 years, 11 months
Re: (ITS#8832) Fix build with LibreSSL 2.7
by brnrd＠freebsd.org
--=_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--
4 years, 12 months
Re: (ITS#8831) Database flags reset in mdb_load
by hyc＠symas.com
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/
4 years, 12 months
(ITS#8831) Database flags reset in mdb_load
by gnoe＠symas.com
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.
---
4 years, 12 months
Re: (ITS#8830) build hardcodes gcc
by hyc＠symas.com
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/
4 years, 12 months
Re: (ITS#8830) build hardcodes gcc
by vcunat＠gmail.com
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-440...
If you can't see why, I'll try to revisit this weirdness to avoid
potential surprises in future.
4 years, 12 months
