OpenLDAP 2.4.52 is now available for download as detailed on our download page:
https://www.openldap.org/software/download/
and should soon be available on all official mirrors:
ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS
This is a maintenance release and is made available for general use. Users of OpenLDAP Software are encouraged to upgrade.
Significant contributors are:
Howard Chu (Symas Corp)
Quanah Gibson-Mount (Symas Corp)
OpenLDAP 2.4.52 (2020/08/28)
Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318)
Added libldap OpenSSL support for multiple EECDH curves (ITS#9054)
Added slapd OpenSSL support for multiple EECDH curves (ITS#9054)
Fixed librewrite malloc/free corruption (ITS#9249)
Fixed libldap hang when using UDP and server down (ITS#9328)
Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324)
Fixed slapd syncrepl regression that could trigger an assert (ITS#9329)
Fixed slapd-mdb index error with collapsed range (ITS#9135)
MD5(openldap-2.4.52.tgz)= d5e6824c58a050a6e43f53c2aa0ca677
SHA1(openldap-2.4.52.tgz)= c65ebaf9f3f874295b72f19a5de9b74ff0ade4ec
Red Hat recently patched the libldap in Enterprise Linux 8 to "support" RFC 6125 in direct violation of the recommendations in section 1.4 of that RFC. Due to the significant issues with RFC 6125 (https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/t…), we consider these changes harmful. It is advised to avoid use of the OpenLDAP libraries as provided by Red Hat Enterprise Linux 8 and its derivatives.
Hello OpenLDAP community,
There have been a number of inquiries recently in regards to RFC 6125 and its support in OpenLDAP. After reviewing the contents of RFC 6125, we felt it important to publicly address the OpenLDAP project's stance on this RFC.
RFC 6125 specifically states it does not supersede existing RFCs. Certificate handling for the LDAP protocol is defined in RFC4513, thus the procedures defined in RFC 6125 do not apply to the LDAP protocol. Additionally, RFC 6125 explicitly excludes the LDAP protocol from consideration in Section 1.4 and Appendix B.3.
Even without the specific exclusions for the LDAP protocol, the OpenLDAP project considers the general concepts in RFC 6125 as harmful. It redefines the purpose of subjectAlternativeName from being an alternative to the commonName to being the only allowable source for consideration unless it is not present in the certificate. This breaks standard practice for commonName going back to at least 1998. Additionally it breaks standard wildcard certs as issued from various Certificate Authorities as the long standing behavior has been to use a commonName=*.example.com, which is not allowed with RFC 6125.
The Subject Naming discussion in Section 2.3 and 2.3.1 is also problematic. Rather than clarify the confusion around Distinguished Names, it just muddles things even further. This is a simple concept and there's no good reason to perpetuate the confusion: DNs are hierarchical names, just like DNS names are hierarchical names. A fully qualified name is an ordered concatenation of names from a root of a naming hierarchy to its leaves.
In DNS the root is "." and the names are written in leaf-to-root order, thus:
com
example.comwww.example.com
LDAP software has adopted this same leaf-to-root order for its string representation of DNs, thus:
dc=com
dc=example,dc=com
dc=www,dc=example,dc=com
Although older X.500 software tended to use a root-to-leaf ordering, just like filesystems use, and older X.509 certificate tools used this as well:
/dc=com
/dc=com/dc=example
/dc=com/dc=example/dc=www
This is still the exact same DN, just using a different convention for string representation.
Ignoring the fact that DNs are hierarchical, and noting that a CN appearing anywhere in the DN can be used to check a service name, flies in the face of over 30 years of practice.
In summary, RFC 6125 breaks long-established practices for weakly supported reasons and fails to enhance understanding of the subject.
OpenLDAP 2.4.51 is now available for download as detailed on our download page:
https://www.openldap.org/software/download/
and should soon be available on all official mirrors:
ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS
This is a maintenance release and is made available for general use. Users of OpenLDAP Software are encouraged to upgrade.
Significant contributors are:
Howard Chu (Symas Corp)
Quanah Gibson-Mount (Symas Corp)
Ondřej Kuzník (Symas Corp)
Ryan Tandy
OpenLDAP 2.4.51 Release (2020/08/11)
Added slapo-ppolicy implement Netscape password policy controls (ITS#9279)
Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650)
Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287)
Fixed slapd to enforce singular existence of some overlays (ITS#9309)
Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227)
Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282)
Fixed slapd syncrepl to use replace on single valued attrs (ITS#9294, ITS#9295)
Fixed slapd-perl dynamic config with threaded slapd (ITS#7573)
Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285)
Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302)
Fixed slapo-ppolicy so it can only exist once per DB (ITS#9309)
Fixed slapo-chain to check referral (ITS#9262)
Build Environment
Fix test064 so it no longer uses bashisms (ITS#9263)
Contrib
Fix default prefix value for pw-argon2, pw-pbkdf2 modules (ITS#9248)
slapo-allowed - Fix usage of unitialized variable (ITS#9308)
Documentation
ldap_parse_result(3) - Document ldap_parse_intermediate (ITS#9271)
MD5(openldap-2.4.51.tgz)= 0d2025896cf1c17af7304ecc57ec9531
SHA1(openldap-2.4.51.tgz)= 4fe7f0e5766d0d9a5431871b581938c05b4eb873
LMDB 0.9.26 Release (2020/08/11)
ITS#9278 fix robust mutex cleanup for FreeBSD