asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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 year, 7 months
New logging system ideas
by Howard Chu
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/
1 year, 10 months
contrib modules to promote to mainline for 2.5?
by Quanah Gibson-Mount
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>
3 years, 1 month
MinGW status.
by 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=17ea0df46f8...
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
3 years, 1 month
2.4 commit review
by Quanah Gibson-Mount
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>
3 years, 2 months
SASL channel-binding changes
by Isaac Boukris
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!
3 years, 2 months
