openldap-devel April 2020

openldap-devel@openldap.org

8 participants
7 discussions

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

New logging system ideas
by Howard Chu 18 Jul '21

18 Jul '21

Just some initial thoughts on what a new logging daemon should do for us: The primary goal - we want to use a binary message format with as few format conversions as possible between log sender and log processor. I'm thinking that we use message catalogs; we will need a tool to preprocess every logging invocation in the source tree and replace them with a integer messageID. So at runtime only the messageID and the message parameters need to be sent, not any plaintext. The message catalog will be compiled into the binary. When it performs its "openlog" to talk to the logging server, it will send the UUID of its catalog. If the logging server doesn't know this UUID, it will transmit the message catalog to the logging server, before doing anything else. (It may make more sense just to use a SHA hash here instead of a UUID.) This way the logging server will work with any version of the binaries, and we don't need to do special coordination to update message catalogs between revisions. The logging server will just know that a specific catalog is to be used with a particular logging session. The message protocol will be length-prefixed. We may even just use DER, since that would allow us to encode arrays of parameters, and other such stuff. The logging server will write the log messages to disk/network verbatim, doing no parsing at all. It may prefix the records with a log session ID, so that a postprocessor can lookup the catalog that belongs to the session, for dumping out as text. The logging server can store its received catalogs in an LMDB database. The postprocessor can then lookup individual messageIDs in this database, interpolate the parameters, and dump out in text. ... that's what I have so far. It's a bit worrisome because of the additional moving parts: message catalog creator, log server, log postprocessor. There's definitely more complexity here, but most of it is moved out of the runtime hot path, which is the main goal. Suggestions? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 12

contrib modules to promote to mainline for 2.5?
by Quanah Gibson-Mount 23 Apr '20

23 Apr '20

Are there any contrib modules that we should consider promoting to mainline for the 2.5 series? I.e., sha2, argon2 seem like potential options. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 11

Re: contrib modules to promote to mainline for 2.5?
by Quanah Gibson-Mount 22 Apr '20

22 Apr '20

--On Wednesday, April 22, 2020 1:04 PM -0700 Philip Guenther <pguenther(a)proofpoint.com> wrote: > Is there a ticket tracking this where the open question(s) for which a > response is needed can be seen? The obvious search of > https://bugs.openldap.org/buglist.cgi?quicksearch=bcrypt There wouldn't be, as it requires the author to contribute it as noted in: <https://github.com/wclarie/openldap-bcrypt/issues/1> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

MinGW status.
by Ryan Tandy 17 Apr '20

17 Apr '20

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=17ea0df46f819… 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

1 0

2.4 commit review
by Quanah Gibson-Mount 02 Apr '20

02 Apr '20

I think the following ITSes would be good to add for 2.4.50. Any objections? ITS#7074 - Fix olcDatabaseDummy init for windows ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy difference ITS#9181 - Fix race on Windows mutex init ITS#9182 - pcache: fix private DB init Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

SASL channel-binding changes
by Isaac Boukris 01 Apr '20

01 Apr '20

Hi all, Following our discussion over cyrus-sasl PR 601 [1], I worked out a new wip patch: https://git.openldap.org/iboukris/openldap/-/commits/cbind_v3 It changes the sasl channel-binding to be passed optionally (none by default), controlled via ldap.conf / slapd.conf, and adds "tls-server-end-point" binding type which is compatible with Windows. In addition, I noticed the current "tls-unique" implementation in openldap doesn't pass the prefix of the channel-binding as defined in RFC 5056, quote: Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII 0x3A). So I fixed that too, by adding "tls-unique:" prefix as per RFC 5929 registration. Note that this won't be compatible with older versions of openldap (say for GS2 users, if any), so it is another reason to not send any bindings by default, to avoid mismatches. I've only tested the openssl client backend code so far (on top of cyrus-sasl PR 601), the rest is pretty much pseudo code for now. I plan to work out the other backends, and add some unit-tests showing the expected binding are being passed by both client and server (tips and help welcome). Thoughts? Refs [1]: https://github.com/cyrusimap/cyrus-sasl/pull/601 https://bugs.openldap.org/show_bug.cgi?id=9189 Thanks!

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel April 2020