MinGW status.

[Ryan Tandy]

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] https://bugs.openldap.org/show_bug.cgi?id=7878#c3
[3] https://www.openldap.org/lists/openldap-technical/201908/msg00033.html

2. Where are we now?

Master branch is in OK shape now. A basic build with OpenSSL and 
default-ish backends/overlays succeeds.


If built WITHOUT --enable-dynamic, it even passes the test suite, with 
one workaround [4]. If built WITH --enable-dynamic, there are various 
issues related to the libtool wrappers: the test processes don't exit 
when killed [5], ITS#2922 occurs, etc. Executing the binaries directly 
seems to work around most of it, but I still have an unexplained failure 
in test058.


RE24 has the code fixes now (in 2.4.50), however, its older libtool and 
autoconf still contain bugs that have been fixed now in master. It 
doesn't produce DLLs due to a libtool bug [6], but the executables can 
be built with the static libs. The test suite needs configure rebuilt 
with a newer autoconf [7], plus all the same caveats as master.


[4]
--- a/tests/scripts/defines.sh
+++ b/tests/scripts/defines.sh
@@ -18 +18 @@
-TESTWD=`pwd`
+TESTWD=`pwd -W`

[5] https://sourceforge.net/p/mingw/bugs/845/ 
https://sourceforge.net/p/mingw/bugs/1783/
[6] haven't found a bug or commit link, but 
https://lists.defectivebydesign.org/archive/html/lmi/2011-06/msg00016.html 
discusses the same problem
[7] 
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=17ea0df46f819a9b64c21151983a5c5b8561fefb

If I've analyzed anything above incorrectly, please let me know!

3. Where to next?

I'd like to write up some up-to-date instructions for building on 
Windows, but I'm not sure where I would post them before the FAQ site is 
replaced.


When I linked with MSYS2's cyrus-sasl package, I encountered heap 
corruption errors. I haven't looked more closely at that yet.


Since a native Windows CI host looks unlikely in the short term, I'd 
like to investigate getting cross builds [8] stable enough to add as a 
CI target. ITS#9087 is a first step in that direction. Obviously it 
wouldn't be able to run tests, but we could at least monitor compile 
failures. There are a few things to deal with, such as configure tests 
that currently run test programs (e.g. "working memcmp"), and providing 
dependency libraries (-lregex).


[8] apt install gcc-mingw-w64-x86-64

cheers,
Ryan

Re: Issue tracker review complete

[Ryan Tandy]

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 delay a release rather than defer features, or sneak 
risky changes into point updates.

Re: back-ndb: retire for 2.5?

[Ryan Tandy]

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

Re: back-sql: retire for 2.5?

[Ryan Tandy]

+1 to making back-sql master only.

Re: New release policy for OpenLDAP

[Ryan Tandy]

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 note, I'd point out this is opposite to 
GNOME's numbering [1] which might occasionally confuse downstreams who 
work with both. Speaking of which, is the odd/even numbering intended to 
apply to the patch version only (2.5.{1,2}) or the minor version 
(2.{5,6}.y) as well?


Why was this particular approach chosen? As opposed to, for example, 
doing feature releases more often (e.g. 2.6 as soon as a few months 
after 2.5), or adding a fourth version component (2.5.y.z) for strictly 
bugfix-only patch releases? Not trying to advocate a change of decision, 
just interested in the thought process...


[1] 
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en#stable-unstable-versions

Re: 2.4 commit review

[Ryan Tandy]

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. It's been in 
Debian since 10.0 and Ubuntu since 19.04, no negative feedback.

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

[Ryan Tandy]

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 that STRERROR(e) triggers deprecation 
warnings on my system:


.../libraries/libldap/os-ip.c:248: warning: `sys_errlist' is deprecated; use 
`strerror' or `strerror_r' instead
.../libraries/libldap/os-ip.c:248: warning: `sys_nerr' is deprecated; use 
`strerror' or `strerror_r' instead

Is replacing occurrences of STRERROR with AC_STRERROR_R a worthwhile 
cleanup? (cf. 62da0b673, ba749eb79, bfd09a16a)


Are there cases where AC_STRERROR_R would be inappropriate? (where the 
non-threadsafe strerror() fallback would be totally unacceptable?)


Thanks.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ryan Tandy]

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 possibly other paremters) if 
they are not found in slapd.conf(5).


For syncrepl at least I understood it was intentional that ldap.conf is 
ignored (since 1cc1f9b). No idea about back-ldap; personally I always 
assumed they were supposed to behave the same.

Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48

[Ryan Tandy]

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 openldap client utils) as I mentioned  earlier.


ldap.conf is only for client utilities.  This is clearly described in 
the ldap.conf(5) man page.  This sounds more to me like we've closed a 
bug with the GnuTLS implementation.


This does appear to be what's happened. I confirm that in 2.4.47, 
back_ldap does pick up the TLS_CACERT setting from ldap.conf, while in 
2.4.48 it does not.


For the record, this is not specific to GnuTLS. I observe the same 
difference with OpenSSL.


6f623df (ITS#8427) is the commit that changed it, as expected. As I 
understand it, the new behaviour is what's intended, although configs 
might need updates per Ondrej's last message on the ITS (duplicating the 
TLS settings for different connection types).


Even if it's considered a bugfix, it might be worth calling out in the 
release notes? Just for the sake of reducing support noise if people are 
unintentionally depending on the old behaviour...


Is there a global place in slapd where one can configure things like CA 
cert and have it defaulted into all TLS clients? I'm not aware of one, 
yet it seems like an obvious thing to provide...

Re: Drop support for GNUTLS and libnss in 2.5?

[Ryan Tandy]

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 yes, I do try to respond and 
investigate GnuTLS related issues. Luckily many of these get handled 
through the Debian bugtracker before this side ever hears of them. But 
I'm only reacting to issues that are reported to me; I'm not an active 
OpenLDAP user myself.



The question is whether this is still revelavant with OpenSSL 3.0.0
moving to Apache-2.0 license [1]. [2] says APL-2.0 is not compatible
with GPLv2 though.


Unfortunately that's correct - the Apache license does not solve the 
issue for binaries containing GPLv2 code without an OpenSSL exception.

Re: libldap vs libldap_r ?

[Ryan Tandy]

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 "libldap" becomes 
canonical starting from 2.5, don't drop the symlink at least until 2.6. 

Re: Google's "Season of Docs"

[Ryan Tandy]

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, but I 
would certainly try to take part in doc reviews and answering questions.

Re: Increase default olcLocalSSF to 128

[Ryan Tandy]

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 existing deployment with required SSF 100, then ldapi 
connections are not permitted and the admin may be expecting that.  
Upgrading slapd would then start allowing those ldapi connections, if 
there is no explicit olcLocalSSF: 71 setting, and the admin might not be 
expecting it, if they didn't read the upgrade notes carefully.


In general, changing defaults in a major release (i.e. 2.5) with 
documentation call-outs should be possible, but hbf's point is that for 
a security setting we should be conservative, and I agree with that and 
withdraw my proposal.

Increase default olcLocalSSF to 128

[Ryan Tandy]

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: slapd's crypt usage is single threaded?

[Ryan Tandy]

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 
module and {SSHA512}) instead of libc crypt?

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

[Ryan Tandy]

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] 
https://anonscm.debian.org/git/pkg-openldap/openldap.git/tree/debian/configure.options

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

[Ryan Tandy]

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 found in it are openldap specific.  This 
should resolve the issue with packagers not packaging the file as 
well.


With my packager hat on - the main thing that would affect whether I 
package the file is not the name, but whether 'make install' installs it 
into the public header directory i.e. /usr/include, and whether it's 
subject to interface stability guarantees similar to ldap.h.


My understanding was the _pvt interfaces are for internal consumption 
and therefore subject to change without notice. I can't really package a 
header, if its API/ABI might change in a patch release because some 
internal slapd or tool code needed a change.


(API/ABI changes across major releases i.e. 2.4->2.5 would be fine.)

If I misunderstood the semantics and it's not "private interfaces that 
could change any time" but rather "OpenLDAP extensions to the LDAP API", 
then great, and let's do it :) and the rename would make sense in that 
case.

Re: ITS review 9/12/2017

[Ryan Tandy]

For RE25, possibly (but unlikely) RE24:

its6035 - slapd requires restart after modifying olcAuthzRegexp

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

[Ryan Tandy]

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 spaces, where the 
original files contain tabs. My review is therefore only based on 
reading the code, not testing it. Please attach the actual git commit 
(use git-format-patch(1)), or link to a branch in a git repository.


I don't know a lot of this code very well, so please forgive any stupid 
questions and try to answer patiently. :)


In os-ip.c, the ldap_socket_bind_addr() function is only called to 
effectively bind LDAP client socket to a local IP address if 
HAVE_GETADDRINFO and HAVE_INET_NTOP are defined.


OK. Does the code still compile and behave reasonably if they aren't? 
I'm wondering if it still makes sense to compile any of the contents of 
addr.c or even ldap_socket_bind_addr itself, for example, if getaddrinfo 
is missing. And I wonder also about the expected return value of 
ldap_set_option() when it's not actually possible to respect the 
requested setting.



Changes to be committed:
 (use "git reset HEAD ..." to unstage)

   new file:   addr.c

Changes not staged for commit:
 (use "git add ..." to update what will be committed)
 (use "git checkout -- ..." to discard changes in working directory)

   modified:   ../../include/ldap.h
   modified:   Makefile.in
   modified:   ldap-int.h
   modified:   options.c
   modified:   os-ip.c


Please also update the ldap_get_option.3 man page. (And hopefully I 
don't need to say this, but I expect Microsoft's documentation is 
copyrighted and simply cloning or paraphrasing it would be a bad idea.)



include$git diff ldap.h
diff --git a/include/ldap.h b/include/ldap.h
index 588e906..0268f0e 100644
--- a/include/ldap.h
+++ b/include/ldap.h
@@ -109,6 +109,8 @@ LDAP_BEGIN_DECL
#define LDAP_OPT_DIAGNOSTIC_MESSAGE0x0032
#define LDAP_OPT_ERROR_STRING  LDAP_OPT_DIAGNOSTIC_MESSAGE
#define LDAP_OPT_MATCHED_DN0x0033
+/* same option code as Microsoft LDAP_OPT_SOCKET_BIND_ADDRESSES */
+#define LDAP_OPT_BIND_ADDRESSES 0x0044


Wouldn't it be more compatible to name the option the same?


/* 0x0034 - 0x3fff not defined */
/* 0x0091 used by Microsoft for LDAP_OPT_AUTO_RECONNECT */
#define LDAP_OPT_SSPI_FLAGS0x0092
@@ -815,6 +817,15 @@ typedef struct ldap_url_desc {
#define LDAP_URL_ERR_BADEXTS   0x0a/* bad or missing extensions */

/*
+ *  data type for ldap socket bind addresses
+ */
+typedef struct ldap_bind_addr {
+struct ldap_bind_addr *lba_next;
+char   *lba_address;
+intlba_family;
+} LDAPBindAddr;


Does this definition need to be exposed to the world? Could it be in 
ldap-int.h?





libldap$git diff os-ip.c
diff --git a/libraries/libldap/os-ip.c b/libraries/libldap/os-ip.c
index c7cee92..fbfb8a9 100644
--- a/libraries/libldap/os-ip.c
+++ b/libraries/libldap/os-ip.c
@@ -209,6 +209,50 @@ ldap_int_prepare_socket(LDAP *ld, int s, int proto )
   return 0;
}

+static int
+ldap_socket_bind_addr(LDAP *ld, int s, int sf, int st)
+{
+   LDAPBindAddr **ba;
+   LDAPBindAddr *bap;


Hmm. The double-pointer is the one with fewer "p"s in its name? :)


+   struct addrinfo hints, *bai;
+   int err;
+   int matched = 0;
+
+   for ( ba = >ld_options.ldo_bind_addr; *ba != NULL; ba = 
&(*ba)->lba_next ) {


What's the use of the double pointer when we're only reading the list? I 
know this idiom is helpful when we want to modify the list, but that's 
not the case here, right? The addr.c functions later on also only use a 
single pointer.



+   bap = *ba;
+   if ( bap->lba_family == sf ) {
+   matched = 1;
+   break;
+   }
+   }
+
+   if ( !matched ) {


This looks like it could perhaps just be if (*ba == NULL), i.e. we fell 
off the end of the list?



+   osip_debug(ld, "ldap_socket_bind_addr: no match\n", 0, 0, 0);
+   return -1;
+   }
+
+   memset( , 0, sizeof(hints) );
+   hints.ai_flags = AI_ADDRCONFIG;


Not AI_NUMERICHOST?

(I'm not necessarily looking for one answer or the other here; just a 
rationale, and the chosen behaviour to be documented.)



+   hints.ai_family = sf;
+   hints.ai_socktype = st;


Did you also test this with a UDP (cldap://) socket? I can't think why 
it wouldn't work, but I'd like to be certain. :)



+
+   err = getaddrinfo( bap->lba_address, NULL, ,  );


Assuming we're _not_ using AI_NUMERICHOST, then does this need to be 
holding the ldap_int_resolv_mutex?



+   if ( err != 0 ) {
+   osip_debug( ld, "ldap_socket_bind_addr: %s getaddrinfo error 
%s\n",
+   bap->lba_address, AC_GAI_STRERROR(err), 0 );
+ 

Re: ITS8529 -- Inclusion in RE24?

[Ryan Tandy]

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: Slapd startup behavior when unable to bind to an interface

[Ryan Tandy]

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 saw this at the time when we were talking about it in IRC, 
but now I can't get it to reproduce again. Guess I screwed up.

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

[Ryan Tandy]

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 Debian main that build-depend on libldap, 77 
mention LDAP_DEPRECATED. I didn't check all of these, but the ones I 
looked at all seemed to be activating it.


http://codesearch.debian.net/perpackage-results/LDAP_DEPRECATED%20-package%3Aopenldap/