openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8335) MDB_MULTIPLE issues
by hyc＠symas.com 13 Feb '17

13 Feb '17

h.b.furuseth(a)usit.uio.no wrote: > On 07/12/15 10:14, h.b.furuseth(a)usit.uio.no wrote: >> Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does >> not warn against 0 items. I suggest supporting 0 items, it >> is a commonly supported convenience elsewhere (e.g. memcpy). > > I.e. supporting it as a no-op. But on second thought I think > that's misleading and EINVAL is better: If the key doesn't exist, > this is an attempt to create a key with no data. Unsupported. > Bryan Matsuo just posted a test case to openldap-technical. EINVAL makes sense here. > datacount > UINT_MAX is truncated to unsigned int: > data[1].mv_size = 0x100000002 puts 2 items. > datacount * datasize can exceed UINT_MAX, which mdb_page_spill() > truncates to unsigned int. Such a massive put() will likely > fail anyway, but it should at least try to spill properly first. We should probably check if mv_size is greater than UINT_MAX and return EINVAL. (Or ERANGE.) >> Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it. Because get only works with a cursor. -- -- 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#8586) load cert+chain from TLSCertificateFile
by sca＠andreasschulze.de 12 Feb '17

12 Feb '17

Am 12.02.2017 um 12:04 schrieb Michael Ströder: > sca+openldap(a)andreasschulze.de wrote: >> as discussed on the technical ML it's uncommon to put chain certificates in >> TLSCACertificateFile or TLSCACertificatePath. In case of a intermediate CA like >> "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to >> /TRUST/ that intermediate for a unrelated purpose. > > We should be more precise here - especially regarding the term "user". agree > IMO it is common to put the whole CA cert chain in the cert configuration of a TLS > server. This is required so that the TLS *client* only has to know the root CA cert > (trust anchor) and the TLS server sends the intermediate certs. Note that some TLS > implementations like GnuTLS require the CA cert chain to be "in order" (bottom-up). As I don't use GnuTLS I can't tell something about it's internals > The real issue here is that TLSCACertificateFile and TLSCACertificatePath are also used > to specify the set of trusted CA certs to validate TLS client certs used by the TLS > client to authenticate. correct. That's also what "man 3 SSL_CTX_use_certificate" mention. > So I'm not sure whether your patch breaks the use-case of having more than one trusted > root CA cert for validating TLS client certs issued by independent CAs. I may imagine a setup with RSA and EC certificates. Two certs are more complex then one. But if an admin decide to use diferent CAs it's his decision for more complexity > I think we might need different directives for trusted CA certs for client cert > validation and the server cert chain (similar what's done on Apache mod_ssl with > SSLCertificateChainFile and SSLCACertificateFile/SSLCACertificatePath). also: I don't us apache, can't tell if that way is is the best. Postfix,dovecot, nginx for example don't require a "SSLCertificateChainFile" directive. > It could be sufficient to simply add the server CA cert chain to TLSCertificateFile and > only add the trusted root CA certs to TLSCACertificateFile/TLSCACertificatePath (and no C > code patch needed for that, maybe review/clarification of the docs). that's what the patch try. currently I tried to add cert+chain to a file used as TLSCertificateFile The chain is ignored as expected and documented in "man 3 SSL_CTX_use_certificate_file" simply replacing SSL_CTX_use_certificate_file by SSL_CTX_use_certificate_chain_file fix that. I now can put cert+chain (excluding a root) ti the file used as TLSCertificateFile. as simple as it could be. But: I'm aware there are other use cases that will break stuff, years old. So my ITS it more intended to point out a problem then simply changing openldap to my needs. Andreas

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 12 Feb '17

12 Feb '17

On 07/12/15 10:14, h.b.furuseth(a)usit.uio.no wrote: > Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does > not warn against 0 items. I suggest supporting 0 items, it > is a commonly supported convenience elsewhere (e.g. memcpy). I.e. supporting it as a no-op. But on second thought I think that's misleading and EINVAL is better: If the key doesn't exist, this is an attempt to create a key with no data. Unsupported. Bryan Matsuo just posted a test case to openldap-technical. datacount > UINT_MAX is truncated to unsigned int: data[1].mv_size = 0x100000002 puts 2 items. datacount * datasize can exceed UINT_MAX, which mdb_page_spill() truncates to unsigned int. Such a massive put() will likely fail anyway, but it should at least try to spill properly first. > Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by michael＠stroeder.com 12 Feb '17

12 Feb '17

sca+openldap(a)andreasschulze.de wrote: > as discussed on the technical ML it's uncommon to put chain certificates in > TLSCACertificateFile or TLSCACertificatePath. In case of a intermediate CA like > "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to > /TRUST/ that intermediate for a unrelated purpose. We should be more precise here - especially regarding the term "user". IMO it is common to put the whole CA cert chain in the cert configuration of a TLS server. This is required so that the TLS *client* only has to know the root CA cert (trust anchor) and the TLS server sends the intermediate certs. Note that some TLS implementations like GnuTLS require the CA cert chain to be "in order" (bottom-up). The real issue here is that TLSCACertificateFile and TLSCACertificatePath are also used to specify the set of trusted CA certs to validate TLS client certs used by the TLS client to authenticate. So I'm not sure whether your patch breaks the use-case of having more than one trusted root CA cert for validating TLS client certs issued by independent CAs. I think we might need different directives for trusted CA certs for client cert validation and the server cert chain (similar what's done on Apache mod_ssl with SSLCertificateChainFile and SSLCACertificateFile/SSLCACertificatePath). It could be sufficient to simply add the server CA cert chain to TLSCertificateFile and only add the trusted root CA certs to TLSCACertificateFile/TLSCACertificatePath (and no C code patch needed for that, maybe review/clarification of the docs). Ciao, Michael.

1 0

Re: (ITS#8485) [PATCH] Adding support for encrypted server private keys
by balmerpeak92＠gmail.com 12 Feb '17

12 Feb '17

--f403045f155e1c46d105484cea3d Content-Type: text/plain; charset=UTF-8 This would be a very helpful feature for me - I have a web server that has to regularly interact with a corporately maintained secure LDAP server. I'd love to be able to store the certs for this interaction encrypted for added security. --f403045f155e1c46d105484cea3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This would be a very helpful feature for me - I have a web= server that has to regularly interact with a corporately maintained secure= LDAP server. I'd love to be able to store the certs for this interacti= on encrypted for added security.<br></div> --f403045f155e1c46d105484cea3d--

1 0

(ITS#8587) correct spelling errors: wrong: emtpy, correct: empty
by sca+openldap＠andreasschulze.de 11 Feb '17

11 Feb '17

Full_Name: Andreas Schulze Version: RE24 testing call (2.4.45) OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211-2.patch Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) there are 4 occurrence of "emtpy" which are supposed to be written as "empty"

1 0

(ITS#8586) load cert+chain from TLSCertificateFile
by sca+openldap＠andreasschulze.de 11 Feb '17

11 Feb '17

Full_Name: Andreas Schulze Version: RE24 testing call (2.4.45) OS: Linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211.patch Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) as discussed on the technical ML it's uncommon to put chain certificates in TLSCACertificateFile or TLSCACertificatePath. In case of a intermediate CA like "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to /TRUST/ that intermediate for a unrelated purpose. from https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_use_certificate.html#NOTES: SSL_CTX_use_certificate_chain_file() should be used instead of the SSL_CTX_use_certificate_file() function in order to allow the use of complete certificate chains even when no trusted CA storage is used or when the CA issuing the certificate shall not be added to the trusted CA storage. The patch andreas-schulze-20170211.patch only apply for openssl.

1 0

Re: (ITS#8581) slapd-meta backend SSL negociation timeout
by louis.chanouha＠test.univ-toulouse.fr 10 Feb '17

10 Feb '17

I tried with ltb's latest Jessie builds but same problem occurs. I fast-checked tls_o.c, i can't find any code relative to handshake timeout (https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries…), but as i never handle any ssl lib code, i can be completely mistaken. On Jessie, default timeout on gnuTLS seems to be 3600 secs, I will try to wait. /usr/local/openldap/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.44 (Feb 8 2016 17:34:53) $ root@debian8:/opt/paquet-openldap-debian/openldap-ltb-2.4.44/servers/slapd

1 0

Re: (ITS#8582) LMDB lockfile/mutex arch dependency
by hyc＠symas.com 09 Feb '17

09 Feb '17

hyc(a)openldap.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.200) > Submitted by: hyc > > > I ran into some corruption problems when running a 64bit LMDB process concurrent > with a 32bit one using MDB_VL32. While LMDB's own structures are all 64bit clean > in a VL32 build, unfortunately pthread_mutex_t structures are not. In > particular, in glibc a pthread_mutex_t can be one of 3 different sizes - 24 > bytes for 32bit runtime on 32bit processor, 32 bytes for 32bit runtime on > x86-64, and 40 bytes for 64bit runtime on x86-64. As such, we cannot safely > share an LMDB environment between 32 and 64bit Linux processes, even when using > MDB_VL32. > > This problem doesn't affect Windows, platforms using SysV semaphores, or > platforms using POSIX named semaphores. I don't currently know whether this is a > problem on other platforms that support POSIX process-shared mutexes. For glibc, I've submitted an enhancement request regarding mutex sizes: https://sourceware.org/bugzilla/show_bug.cgi?id=21119 -- -- 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#8584) reloadhint for syncprov overlay should default to TRUE
by quanah＠symas.com 07 Feb '17

07 Feb '17

> On Feb 7, 2017, at 10:25 AM, hyc(a)symas.com wrote: >=20 > Quanah Gibson-Mount wrote: >> --On Tuesday, February 07, 2017 8:53 AM +0000 Howard Chu <hyc(a)symas.com> w= rote: >>=20 >>=20 >>> The relevant part of the doc is "It must be set TRUE when using the >>> accesslog overlay for delta-based syncrepl support." Otherwise it has no= >>> effect, so there is no reason to change it in the default case. >>=20 >> Actually, what the manpage says is: >>=20 >> This option should be set TRUE when working with >> newer releases that properly support this flag. It must be set >> TRUE when using the accesslog overlay for delta-based syncrepl >> replication support. >>=20 >> So, that clearly states it should *always* be TRUE unless you have a 2.3.= 11 or >> earlier consumer, which is technically not allowable. There is zero reas= on >> for this tunable to exist. It should be deprecated and the internal code= >> changed to simply set the flag to TRUE. One less item for anyone to have= to >> ever deal with is a win. >=20 > "when working with newer releases that properly support this flag." >=20 > The syncrepl consumer only pays attention to this flag in delta-sync. Ther= e is=20 > no reason to use reloadhint in regular syncrepl. Turning it on by default o= nly=20 > slows down the refresh negotiation in regular syncrepl. >=20 > --=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/ >=20 Then the man page needs updating since the information on it is blatantly wr= ong. The "newer releases" is clearly indicated to be anything later than 2.= 3.11. --Quanah=

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