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, 4 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, 8 months
Re: New OpenLDAP TLS backend? (wolfSSL)
by Hayden Roche
Quanah and Howard,
Thanks for your quick replies! I'm glad to hear there's interest in this. I
think 2.6 is a more realistic target, as I'll need to get my boss to
allocate time for this work amongst other wolfSSL tasks I've been assigned.
Look forward to a merge request in the (hopefully near) future!
Thanks,
Hayden
On Thu, Feb 25, 2021 at 1:17 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Thursday, February 25, 2021 12:38 PM -0600 Hayden Roche
> <haydenroche5(a)gmail.com> wrote:
>
> > (thanks JoBbZ). I was also pointed to this
> > issue in your issue tracking system, where a developer (Quanah
> > Gibson-Mount)
>
> Same person. ;)
>
>
> > Is there still interest in getting wolfSSL working with OpenLDAP's latest
> > version and integrated upstream?
>
> OpenLDAP 2.4 is closed to development. If you want this in for OpenLDAP
> 2.5, you'll need to get the work in ASAP, otherwise it will have to wait
> for 2.6
>
> Generally:
>
> Sign up for an account on our gitlab instance: https://git.openldap.org
>
> Fork a copy of the openldap repo.
>
> Create a branch for ITS9303 and do the work in that branch
>
> Push the branch
>
> Open a merge request for review
>
> Additionally, you'll need to add an IPR statement to ITS#9303 as
> documented
> at <https://www.openldap.org/devel/contributing.html#notice>
>
> A link to the MR should also be put into the ITS.
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
1 year, 10 months
ldap_sasl_interactive_bind_s and LDAP_SASL_QUIET
by Jordan Brown
ldap_sasl_interactive_bind_s prints SASL-related messages on stderr by
default, unless you specify LDAP_SASL_QUIET.
This seems wrong. The whole point of the "interact" function is to
handle any required conversation with the user. In particular, in a GUI
application these messages won't go to the user; more likely they will
just clutter up some log.
Would the OpenLDAP community be receptive to a patch that directs these
messages through the "interact" function?
(I think they have very little value and should just be dropped; that
would be OK too.)
SASL username: somename(a)EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
2 years
Some suggested 2.5 code cleanups/renames
by Hallvard Breien Furuseth
Hello.
slap_op_time(time_t *t, int *nop) could previously be called with any
2 arg of those types. But now it modifies nop[1], so old code other
than slap_op_time(&op->o_time, &op->o_tincr) gets a bad memory write.
Source-code compat looks like a misfeature now. I'd rather rename and
re-prototype: slap_op_gettime(Operation* or some new time-struct*).
==
Another fake array: Let's replace bi_op_bind..bi_chk_controls in
BackendInfo with macros referring into a new bi_op_func[14]. Today
(&bi->bi_op_bind) is used as an array here: grep -r '(&.*_bind)'
And apply 'contrib/slapd-tools/wrap_slap_ops -u * | patch -p0',
though that can wait a bit more - until RE24 is really surely not
going to get new releases and merge conflicts with the patch.
(Hm. The "delete newlines at EOF" cleanup doesn't belong there.)
Related issue: slap_operation_e was the indexes to (&bi->bi_op_bind),
but now it has op_txn too corresponding to bi_op_txn with a different
prototype. 'grep -r op_last' shows code mentioning op_last which has
not been updated to match this. Unsure what to do about this. Other
than commenting the enum afterwards, anyway:-)
==
Any chance of wrapping struct ldapoptions' contents in some structs?
Today, if a new field is added but the corresponding NULLARG is not
updated to match, the later NULLARGs initialize the wrong fields and
can fail. As in ITS#9332 (init ldo_tls_require_san).
So anyway, one struct per LDAP_blah_NULLARG. Then replace most
NULLARGs with {0}. But must add lots of macros, for the old fields.
==
Hallvard
2 years
Merge request management
by Ondřej Kuzník
It's a good development that we have more merge requests coming in and
things are getting looked at. As things pick up, we need to be able to
quickly identify which requests are waiting on review, where we're
waiting on the review comments to be addressed.
I guess we can keep switching the WIP: flag on the request for that one
and let authors remove it when ready again.
Similar when a different reviewer is needed (e.g. when I've added
substantial code to an existing request) or a configure update or a
backport to an older release should be done post-merge, labels might or
might not be the best fit, there's also way to request review from a
particular person.
BTW non-project members are invited to help with review and testing,
it's a great way to get familiar with the codebase and helps the project
move faster and at higher quality.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
2 years
