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
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
back-ndb: retire for 2.5?
by Quanah Gibson-Mount
The back-ndb backend has never been finished, and relies on partnership
with a corporation that has no desire to continue the work since it
acquired the original entity involved.
I would suggest then that it be removed from the 2.5 release tree and left
master only.
--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
Issue tracker review complete
by Quanah Gibson-Mount
I've gone through and looked at all of the open issues that were in the
OpenLDAP product queue. The end result of this is that numerous duplicate
issues, invalid issues, and issues where we never got any response after
asking for more information have been closed out appropriately.
As a part of this I've gone through and marked many of the bugs with target
milestones and sometimes keywords.
Any issues with a target milestone of 2.5.0 and a keyword of OL_2_5_REQ is
an item that should likely be fixed for OpenLDAP 2.5. If it is not going
to be fixed for 2.5, then we need to come to a decision on what release
series we plan on fixing it in. I.e., I generally consider these high
priority items. Often these are things we've put off doing for 2.4 due to
disruption/incompatible API changes, etc, but are generally necessary for
the overall improvement of OpenLDAP. A number of these issues already have
patches. Some of them are documentation items that are likely not too hard
to deal with, and I've self-assigned many of those. There are a total of
175 items in this list:
<https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=C...>
Any issues with a target milestone of 2.5.0 but no keyword of OL_2_5_REQ
are items that need further review by other team members. I put items in
this category that seem of general interest, but may be more appropriate
for a later release, or perhaps remain unscheduled at this time. There are
188 issues in this list:
<https://bugs.openldap.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=C...>
There is one open issue with the 2.4.50 milestone that I'll be taking care
of.
All other issues I've left unassigned. This does not mean they have no
value, but they do not seem critical for the OpenLDAP 2.4.50 or 2.5
releases and can be re-examined at a later time.
All of this should help anyone who has expressed a desire in the past to
work with the project -- There is now a well sorted set of issues that need
addressing. Some of these items are fairly straight forward, especially
documentation updates. Feel free to sign up to gitlab, fork the repo, and
submit merge requests for issues to be reviewed. Please add any merge
request links to the related issue in the tracker as well.
Overall, given the list of items in the first category, I'm not sure the
2.5-odd/even track is the best route. I'm personally leaning more towards
2.5, 2.6, 2.7, etc, where each of these releases is of a short duration.
There seems to be enough work at this time to support more frequent minor
version releases and that would allow us to sucessively improve the
product. Having defined sets of issues for given target release milestones
should help significantly as far as planning and resource allocation is
concerned.
Regards,
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
back-sql: retire for 2.5?
by Quanah Gibson-Mount
One thing that came up repeatedly in going through the ITS system is issues
with back-sql (A quick count gives me 23). Given that this backend has
always been marked experimental and has numerous bugs, I would suggest that
unless someone steps up who is willing to support it that it be removed
from the 2.5 release series (i.e., make it master only until someone is
willing to maintain it).
--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
CVS... should it stay or should it go now?
by Quanah Gibson-Mount
One of the things we did not migrate over from Gauss was the old CVS
repository.
However, there are references in the old -software archives (and possibly
-technical as well), and existing bug reports, such as
<https://bugs.openldap.org/show_bug.cgi?id=831#c6> which have links that
will no longer work without the old CVS repository being present, although
all of these changes of course do exist in the git repo, just with git
change IDs.
Is there anyone who feels it is worthwhile to preserve the old CVS
repository so that these references can still be examined directly w/o
having to parse through the git history to find them? If so, we can
certainly restore the CVS repo on the new system.
Regards,
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
archiving test
by Quanah Gibson-Mount
just an archiving test, ignore :P
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
3 years, 2 months