openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs