Re: Update/drop cruft: LDAP_DEPRECATED, CLDAP, C version

On Sat, Jun 20, 2015 at 05:33:50PM -0700, Quanah Gibson-Mount wrote: I rarely see traffic from people any longer on how to convert code using them to the new functions (I.e., the majority of code utilizing libldap seems to have moved to the non-deprecated fuctions). Out of 151 packages in

Re: Slapd startup behavior when unable to bind to an interface

On Sat, Jan 09, 2016 at 03:48:12PM -0800, Quanah Gibson-Mount wrote: This is fairly trivial to reproduce. As a non-privileged user, simply do: -h "ldap:// ldapi://slapd.sock" It will fail to bind to 389, but bind to the LDAPI socket anyway, and continue the startup process. I was sure I

Re: ITS8529 -- Inclusion in RE24?

On Wed, Feb 22, 2017 at 11:01:17AM -0800, Quanah Gibson-Mount wrote: Does anyone have some good concrete reasons why it should not go into RE24? I think it's a good change for RE24. The error message is clear enough.

Re: ITS#8654 - Option for LDAP client to bind to a local address

On Mon, Jun 12, 2017 at 10:15:56PM +, Daniel Le wrote: Please review the code change. The diff is against the master branch of git://git.openldap.org/openldap.git. I'm not able to apply the patch from this email. The whitespace in the context has been mangled - your mail only contains

Re: ITS review 9/12/2017

For RE25, possibly (but unlikely) RE24: its6035 - slapd requires restart after modifying olcAuthzRegexp

Re: RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22)

On Sun, Feb 11, 2018 at 01:11:09PM -0800, Quanah Gibson-Mount wrote: OpenLDAP 2.4.46 Engineering 'make check' passed on Debian unstable with the Debian build flags (via dpkg-buildflags(1)) and configure options [1]. Will try to squeeze in some manual testing, maybe this weekend... [1]

Re: slapd's crypt usage is single threaded?

On Fri, Feb 16, 2018 at 12:01:37PM -0600, Jesse Hathaway wrote: # {CRYPT}$6$rounds=1000$ykk4zGD3ODNR$iMP/zYeisoWTYgxLtPv1qzoo/dVrYQLAb9sKlRMBgPTfFrr9lTzEEkJ9NcFdGI/MiRxHSx/1x3rnw3RkNRMer/ # 'everyone loves butter' Have you tested this using the native SHA-2 support (slapd-sha2 contrib

making ldap_pvt.h public (was: Re: RE24 testing call #1 (2.4.46) LMDB RE0.9 testing call #1 (0.9.22))

On Thu, Feb 15, 2018 at 09:09:53AM -0800, Quanah Gibson-Mount wrote: The "ldap.h" file is specifically for RFC defined interfaces. I discussed this with Howard, and we thought that the best way to address this issue would be to rename "ldap_pvt.h" to "openldap.h", to indicate that the methods

Re: Increase default olcLocalSSF to 128

On Thu, Jul 26, 2018 at 01:34:52PM +0200, Hallvard Breien Furuseth wrote: I were implementing a new LDAP server, I'd pick a higher default. But I'd rather not weaken security defaults in existing software. In IRC, hbf went into a little more detail on what was meant by this: If you have an

Increase default olcLocalSSF to 128

I propose increasing the default olcLocalSSF to 128. Mentioned initially on IRC, now bringing it to the list for completeness and archival. In typical setups people want to require TLS *or* ldapi, and ssf=128 seems like a pretty common olcSecurity setting for current systems. thanks Ryan

Re: Google's "Season of Docs"

On Wed, Mar 13, 2019 at 08:54:20PM +0100, Michael Ströder wrote: Does anybody here think it's worth to give this a try? https://developers.google.com/season-of-docs/docs/ I was wondering the same - thanks for bringing it up! I don't think I can commit enough time to participate as a mentor,

Re: libldap vs libldap_r ?

On Mon, Mar 18, 2019 at 05:31:34PM +, Howard Chu wrote: I would probably keep "libldap" as the canonical name. ++ We can completely drop the "libldap_r" name or just keep it as a symlink for a while, removing it after a year or so. I'd maybe make that "after a release or so" i.e. if

STRERROR(e) vs AC_STRERROR_R(e,b,l)

I'm working on adding debug logging for GnuTLS errors. I'd like to add a strerror() inside tlsg_getfile() as part of this. First question: I found STRERROR(e) and AC_STRERROR_R(e,b,l). It looks like AC_STRERROR_R should be preferred for new code. Is that correct? Second question: I noticed

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

On Sat, Jul 20, 2019 at 09:40:53AM -0700, Quanah Gibson-Mount wrote: --On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas wrote: I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48

Re: Drop support for GNUTLS and libnss in 2.5?

On Sat, Jul 20, 2019 at 12:13:38PM +0200, Michael Ströder wrote: The support for GNUTLS was requested by Debian folks because of OpenSSL licensing paranoia. Does anybody maintain the stuff? As the Debian maintainer I consider the GnuTLS support primarily my responsibility at this point, so

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote: Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and

Re: 2.4 commit review

On Fri, Nov 01, 2019 at 09:31:07AM -0700, Quanah Gibson-Mount wrote: ITS#8753 Set minimum GnuTLS version to 3.2.2 Not on its own. Only needed if the rest of that ITS goes (guessing no). ITS#9069 Do not call gnutls_global_set_mutex() Subject to hyc's approval, but I think this could go in.

Re: New release policy for OpenLDAP

On Fri, Jan 24, 2020 at 08:12:49AM -0800, Quanah Gibson-Mount wrote: Starting with OpenLDAP 2.5, the OpenLDAP project will use a new release process. Odd numbered releases will contain only bug fixes Even numbered releases will allow for minor new features Works for me. Similar to Gavin's

MinGW status.

1. Why do I care about Windows? After seeing knowledgeable people say several times that building OpenLDAP on Windows worked fine for them [1][2][3], but failing my first attempts, I decided it should damn well work for me too! [1] https://bugs.openldap.org/show_bug.cgi?id=7878#c1 [2]

Re: back-sql: retire for 2.5?

+1 to making back-sql master only.

Re: back-ndb: retire for 2.5?

I'd go further and propose simply deleting back-ndb. Do we know of anyone using it?

Re: Issue tracker review complete

This is fantastic, and I really appreciate you doing the work. Having everything categorized and milestoned is a major improvement. I'm a fan of smaller and more frequent releases in general so I'm happy to hear that suggestion. Gets changes out to users sooner, but also reduces the urge to