openldap-devel

openldap-devel@openldap.org

2 participants
1422 discussions

Website issues
by Howard Chu 09 Jul '25

09 Jul '25

While static page serving has gone on uninterrupted, the CGI for bugzilla and manpages was timing out due to some kind of spam attack. I've tweaked the fail2ban config to catch more of the offending requests, and increased the bantime for these requests to 72 hours, up from the default of 10 minutes. Bugzilla appears to be running normally now. Considering increasing the bantime further, we'll see. Reply to this thread if you notice any other problems in the next few days. -- -- 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 0

OpenSSL in the Wild survey (fwd)
by Quanah Gibson-Mount 01 Jul '25

01 Jul '25

Howard do you want to fill out this survey? Not sure if they're taking feedback. ;) --Quanah ------------ Forwarded Message ------------ Date: Wednesday, June 18, 2025 6:33 PM -0700 From: Jon Ericson <jone(a)openssl.org> To: openssl-users <openssl-users(a)openssl.org> Subject: OpenSSL in the Wild survey Hi all, I'm the communities manager for the OpenSSL Foundation and I could use your help. We'd like to know who uses OpenSSL and how it's used. To that end, we're asking everyone to complete this short, one-page survey: https://secure.lglforms.com/form_engine/s/85lymH2pkvzm26KyuxafBQ Not only will it help us understand the people who use the library, we also know it will surface some interesting stories. When you're done with the survey, why not send it to other people who use OpenSSL in their work? Thanks, Jon -- You received this message because you are subscribed to the Google Groups "openssl-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe(a)openssl.org. To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/CAK9c5VYUnfA5 Yab6jk8bRkL4NcxV6QqhDatfYYdj_t3m%3DmZz1Q%40mail.gmail.com. ---------- End Forwarded Message ----------

1 0

Re: Please authorise my Git Lab account
by Arran Cudbard-Bell 24 Jun '25

24 Jun '25

Hello openldap-devel, Could you please approve my gitlab account. uid: arr2036, email: a.cudbardb(a)freeradius.org. Many Thanks, -Arran

2 1

Referral chasing, ITS#10356
by Howard Chu 12 Jun '25

12 Jun '25

I note that there is a default REFHOPLIMIT defined in ldap-int.h and a refhoplimit field in the ldap options structure. But there is no option defined to change it via ldap_set_option(). Seems like a 26 year oversight. Should that be added for 2.7? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

ITS#10160 + gitlab account validation
by Alexandre Jousset 07 Feb '25

07 Feb '25

Hi 🖖, I commented on ITS#10160 about "adding negset and negurl for slapo-constraint" that was left unanswered for about one year. I'd like to have my account on the gitlab instance (username "mid") validated so I can submit an MR, please 🙂 Thanks! -- -- \^/ -- -- -/ O \------------------------------------ -- -- | |/ \| Alexandre (Mid') Jousset | -- -- -|___|------------------------------------ --

2 2

ITS#9739 + gitlab account validation
by Zhixu Liu 06 Feb '25

06 Feb '25

Hi, I commented on ITS#9739 about "Undefined reference to ber_sockbuf_io_udp" please approve the account request on gitlab from this email address, thanks. -- Z. Liu

2 1

ldap_get_values() called on binary data - does this return an error, or garbage data?
by Graham Leggett 03 Apr '24

03 Apr '24

Hi all, Looking back in time to the definitions of ldap_get_values() and ldap_get_values_len(), we are told that "If the attribute values are binary in nature, and thus not suitable to be returned as an array of char *'s, the ldap_get_values_len() routine can be used instead." This has been historically vague - first off, what happens if an attempt is made to call ldap_get_values() on binary data, do you get an error, or garbage data? The source isn't giving me a clear answer. Second question is how do you know which of ldap_get_values() or ldap_get_values_len() to call? Obviously you can manually know this, but I'm interested in automated behaviour. What is the canonical way to discover that if you queried a jpegPhoto (for example) that the result would be binary? To be clear, the end goal it to patch the following documentation to make this clear: https://www.openldap.org/software/man.cgi?query=ldap_get_values&apropos=0&s… Regards, Graham --

4 6

Dynamically managed groups, etc
by Howard Chu 26 Feb '24

26 Feb '24

The recent work on expanding dynamic group functionality in the dynlist overlay seems to have been a bad idea. It makes an already fairly complex overlay even more complicated, and it puts a lot more work into the read side of operations, which adds up to quite noticeable slowdowns in search performance on deployments that make heavy use of dynamic groups with large memberships. It appears that in these situations, the approach used in the autogroup overlay (which has been in contrib since 2007) is better. It moves all of the membership management into the write side of operations, updating memberships whenever dynamic group definitions are modified, or when member entries are written/updated/etc. As such, it allows dynamically defined group memberships to be read/searched at full speed, as if they were static groups. The search performance difference between autogroup and the dynlist approach is pretty drastic when large groups and large numbers of groups are in use. As such I believe autogroup should be recommended, going forward, and we should move it from contrib into the core code. For similar reasons, dynamically managing memberOf attributes in dynlist also has a major impact on search performance. And as alluded to before, adding that functionality to dynlist has made the code quite a bit more complex. Again for performance reasons, it's better to manage this attribute on the write side, updating a real attribute in the DB when groups and memberships are modified, instead of doing the lookup work on the read/search side. As such, we should reverse the decision to deprecate the memberof overlay. There were a couple problems that the overlay presented in replication environments before, that prompted us to deprecate it, but I believe those problems have now been resolved. The first one, referenced in ITS#7400, had to do with the actual memberof attributes getting replicated even though they weren't meant to be. The solution for that should have been to specify that memberof should be excluded from replication using "exattr" in a syncrepl consumer config. The exattr option wasn't behaving as intended in the past, and using it would cause data desyncs, but that problem was fixed long ago. The other problem was simply due to the lack of ordering guarantees in syncrepl refreshes, which prevented the memberof overlay from updating an member's memberof attribute if the group entry got replicated before the member entry. That problem has been solved in ITS#10167, simply adding a check whenever new entries are added, to see if they're already members of any existing groups. As such, the memberof overlay should be perfectly fine for use in replication scenarios now. More testing of those scenarios is welcome. With statically managed member and memberof attributes, the major hits to search performance have been removed. We're still trying dynamically managed nesting of groups though, which is what the new nestgroup overlay (ITS#10161) is for. Again, we need testing to see how much performance impact there is from this much-reduced overhead in the read/search side of things. The config is also a lot easier to understand in its own overlay, instead of shoe-horned into the dynlist config. Testing and feedback appreciated. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

LMDB and fsync failures
by Howard Chu 09 Feb '24

09 Feb '24

If anyone remembers fsync-gate https://danluu.com/fsyncgate/ which showed a lot of vulnerabilities in other popular DBMSs, some other research was published on the topic as well https://www.usenix.org/conference/atc20/presentation/rebello I originally discussed this on twitter back in 2020 but wanted to summarize again here. As usual with these types of reports, there are a lot of flaws in their test methodology, which invalidates some of their conclusions. In particular, I question the validity of the failure scenarios their CuttleFS simulator produces. Specifically, they claim that multiple systems exhibit False Failures after fsync reports a failure, but actually (partially) succeeded. In the case of LMDB, where a 1-page synchronous write is involved, this is just an invalid test. They assume that the relevant sector that LMDB cares about is successfully written, but an I/O error occurs on some other sector in the page. And so while LMDB invalidates the commit in memory, a cache flush and subsequent page-in will read the updated sector. But in the real world, if there are hard I/O errors on these other sectors, they will most likely also be unreadable, and a subsequent page-in will also fail. So at least for LMDB, there would be no false failure. The failure modes they're modeling don't reflect reality. Leaving that issue aside, there's also the point that modern storage devices are now using 4KB sectors, and still guarantee atomic sector writes, so the partial success scenario they describe can't even happen. This is a bunch of academic speculation, with a total absence of real world modeling to validate the failure scenarios they presented. The other failures they report, on ext4fs with journaled data, are certainly disturbing. But we always recommend turning that journaling off with LMDB; it's redundant with LMDB's own COW strategy and harms perf for no benefit. Of course, you don't even need to trust the filesystem, you can just use LMDB on a raw block device. -- -- 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 0

OpenSSL provider support in openldap: OSSL_STORE_open()
by Graham Leggett 14 Jan '24

14 Jan '24

Hi all, A search in the openldap source shows we don’t yet support the OpenSSL3 provider OSSL_STORE_open() call, which takes a URL as a parameter. I’m happy to patch the openldap client to support this, would it make sense to add a LDAP_OPT_X_TLS_URL option to ldap_option_set()? Regards, Graham —

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel