- openldap-bugs - openldap.org

[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9524 Issue ID: 9524 Summary: Removing last entry in database triggers MDB_PROBLEM Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- With a fresh database, if you have have an open read transaction, and you create a new entry in a write transaction and commit it, and then create a new transaction and delete that entry, when you commit, it will return an MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list check. This seems to occur on mdb.master3, but not mdb.master. Here is a minimal example/test-case of how to reproduce: MDB_env* env; mdb_env_create(&env); int rc, flags = 0; mdb_env_open(env, "test", flags, 0664); MDB_txn* readonly_txn; mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn); MDB_txn* txn; MDB_dbi dbi; mdb_txn_begin(env, nullptr, 0, &txn); mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi); MDB_val val; val.mv_data = (void*) "test"; val.mv_size = 4; mdb_put(txn, dbi, &val, &val, 0); mdb_txn_commit(txn); mdb_txn_begin(env, nullptr, 0, &txn); mdb_del(txn, dbi, &val, nullptr); rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM (let me know if this should be submitted differently) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9910] New: undefined MDB_FDATASYNC in mdb.master3 on macOs
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9910 Issue ID: 9910 Summary: undefined MDB_FDATASYNC in mdb.master3 on macOs Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 912 --> https://bugs.openldap.org/attachment.cgi?id=912&action=edit patch I am using the mdb.master3 branch which contains the encryption codebase. While testing on macOS, compilation fails with "undefined MDB_FDATASYNC" This is because commit #d85fe32 https://git.openldap.org/openldap/openldap/-/commit/d85fe32dab55b88cec25fc7… introduced a bug in the sense that the #elif on line 167 is not executed if the previous #elif is true. So when defined(__APPLE__) && !defined(MDB_USE_ROBUST) is true, the following #elif is skipped. But this seconf @elif is essential, as it defines MDB_FDATASYNC Proposed patch: --- libraries/liblmdb/mdb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 5bdec70..b54c8ae 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -164,9 +164,10 @@ typedef SSIZE_T ssize_t; #if defined(__FreeBSD__) && defined(__FreeBSD_version) && __FreeBSD_version >= 1100110 # define MDB_USE_POSIX_MUTEX 1 # define MDB_USE_ROBUST 1 -#elif defined(__APPLE__) && !defined(MDB_USE_ROBUST) -# define MDB_USE_POSIX_SEM 1 #elif defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__) +# if defined(__APPLE__) && !defined(MDB_USE_ROBUST) +# define MDB_USE_POSIX_SEM 1 +# endif # if !(defined(MDB_USE_POSIX_MUTEX) || defined(MDB_USE_POSIX_SEM)) # define MDB_USE_SYSV_SEM 1 # endif -- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9911] New: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9911 Issue ID: 9911 Summary: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- In mdb.master3, when running some test suite, the transaction commit fails with MDB_PROBLEM: Unexpected problem - txn should abort The operation that where executed on a blank database: mdb_env_create mdb_env_open with CREATE mode mdb_txn_begin RW mdb_put one key value mdb_txn_commit mdb_txn_begin RW mdb_drop mdb_txn_commit This last commit fails with : MDB_PROBLEM: Unexpected problem - txn should abort My investigation shows that the lines 4401-4403 are triggered: if ((unsigned)txn->mt_loose_count != txn->mt_u.dirty_list[0].mid) { rc = MDB_PROBLEM; /* mt_loose_pgs does not match dirty_list */ goto fail; } And this is because of the commit #12ee1a2 "Use mdb_page_loose() more" https://git.openldap.org/openldap/openldap/-/commit/12ee1a2d7104616ccb812db… that does a mdb_page_loose instead of a mdb_midl_append on line 9496. Reverting this commit solves the problem. This commit seems to be a non essential optimization. But you will see into it as i am not so familiar with the refactoring that Hallvard Furuseth did back in July 2017. It would be nice to have an official fix from you, instead of this revert I did temporally to be able to continue working. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Using self signed certificate causes ldap_sasl_bind_s() error
by rinchive＠gmail.com 20 Sep '22

20 Sep '22

Hi. I'm trying to use C code of your gitlab repository to make a program that can bind to remote LDAP server. I have some problems with using self signed certificate in openldap server. When I try to connect to remote LDAP server with SSL connection, ldap_sasl_bind_s return this error : "Can't contact LDAP server (-1) additional info: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) " At the same time, server prints like this : 632973de conn=1018 fd=12 ACCEPT from IP=172.17.0.1:57250 (IP=0.0.0.0:636) TLS: can't accept: A TLS fatal alert has been received.. 632973de conn=1018 fd=12 closed (TLS negotiation failure) I use docker image to build an openldap server for test and made my own CA certificates, server's private key and certificate for TLS connection. On client program side, I set some options related to TLS connection. I set LDAP_OPT_X_TLS_REQUIRE_CERT to LDAP_OPT_X_TLS_NEVER, and set LDAP_OPT_X_TLS_CACERTDIR, LDAP_OPT_X_TLS_CACERTFILE to the path that server's CA certificate file is stored. I think I set all options that I can do on client side, but client always verify server's certificate and return "certificate verify failed (self signed certificate in certificate chain)" this error. It is okay to bind without TLS negotiation on client program. Also I made a connection with the server using LDAPAdmin which is windows ldap client program and it makes TLS connection successfully. Is there other option or some codes to be executed to make a secure connection using self signed certificate? I've been struggling with this error for a couple of weeks and not able to find a solution. Can I make a TLS connection with the server that uses the self-signed certificate?

1 0

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 15 Sep '22

15 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #8 from Cliff <cwheat(a)sterlingandzoe.info> --- Thank you for the reply and my apologies for the lack of clarity. Upon further testing, I was unable to reproduce the behavior using a command line application, ldapsearch. I should have done that before submitting the bug. If you have been assigned this issue then please close it. I hope this is more clear: When attempting to display all of the subordinate partitions in the root partition I was only able to see a portion. Those displayed results were all of the same naming context, relative DN c=* or o=*. There is some form of filtering done by the LDAPBrowser GUI. This does not happen using ldapsearch. The problem is not in slapd as I initially thought. Thanks again for your reply. --Cliff On Monday, September 12, 2022 at 12:44:54 PM EDT, <openldap-its(a)openldap.org> wrote: https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9339 Issue ID: 9339 Summary: Add syncrepl status in cn=monitor Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Patch coming to expose some consumer state in cn=monitor Sample entry: # Consumer 001, database 2, databases, monitor dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 001 creatorsName: modifiersName: createTimestamp: 20200906160447Z modifyTimestamp: 20200906160447Z olmSRProviderURIList: ldap://localhost:9011/ olmSRIsConnected: TRUE olmSRSyncPhase: Persist olmSRLastConnect: 20200906160448Z olmSRLastContact: 20200906160453Z olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000 000 olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000 000 entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9853] New: lastbind-precision conversion fails from slapd.conf to cn=config
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9853 Issue ID: 9853 Summary: lastbind-precision conversion fails from slapd.conf to cn=config Product: OpenLDAP Version: 2.6.2 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When converting a slapd.conf file to cn=config, the "lastbind-precision" value is not preserved. slapd.conf: lastbind-precision 300 cn=config value: olcLastBindPrecision: 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9437 Issue ID: 9437 Summary: Add OTP module to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its OTP module for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6035] slapd requires restart after modifying olcAuthzRegexp
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=6035 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • f3ed13fa by Ondřej Kuzník at 2022-09-01T10:09:27+01:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE26: • d598f537 by Ondřej Kuzník at 2022-09-12T20:43:29+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE25: • 1b80eb42 by Ondřej Kuzník at 2022-09-12T20:43:41+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9817] New: rwm overlay : Issue with DN containing special characters
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9817 Issue ID: 9817 Summary: rwm overlay : Issue with DN containing special characters Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, I'm using rwn to select the database useg for bind operations based on the result of a rewriteMap requets. Sample configuration in global section : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Everything goes fine until I use DN with special characters, like ',' or '['. For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local' In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect syntax, as special caracters are not being escaped. I have to use some ugly tricks to escape these caracters, as shown below : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Rewriting for ',' rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2" # Adding a special '#' (asserting it in none of my DNs) suffix for special characters, in order to escape them without looping forever rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3" # Escaping of special characters with dedicated '#' suffix, avoiding infinite loops rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Could there be a way to integrate the ldap escape mechanism when making an variable assignment (like using a '#' character in place of the usual '&') ? Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 21

[Issue 9438] New: Add remoteauth overlay to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9438 Issue ID: 9438 Summary: Add remoteauth overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its remoteauth overlay for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 09 Sep '22

09 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #6 from Cliff <cwheat(a)sterlingandzoe.info> --- On Fedora Core 36, @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ openldap Included static backends: config ldif monitor mdb using LDAP Browser\Editor v2.8.1: While attempting to add subordinate naming contexts off of base DN "" (RootDSE), slapd will only show such subordinate naming contexts if they are of the same RDN attribute. For instance, using all of FC36's trusted CA certificates DN, which boil down to those based at c=?, or o=?, only those of the same attribute will display as subordinates to "". I either get all c= or o=, but not both. The subordinate naming context attribute that comes in the configuration file determines which attribute will be shown. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9905] New: The test case 043 execution failed
by openldap-its＠openldap.org 05 Sep '22

05 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9905 Issue ID: 9905 Summary: The test case 043 execution failed Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- Test case 043 failed after I added #9823 pr to my openldap-2.6.0. Some logs may be useful to you. >>>>> Starting test043-delta-syncrepl for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entries in the provider... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Using ldapmodify to modify provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery... Modifying more entries on the provider... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... Stopping consumer to test recovery after logpurge expired... Modifying even more entries on the provider... Configuring logpurge of 1 second... Waiting 4 seconds for accesslog to be purged... Using ldapsearch to check if accesslog is empty... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ >>>>> Failed test043-delta-syncrepl for mdb after 0 seconds (exit 1) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9358 Issue ID: 9358 Summary: back-mdb may return accesslog entries out of order Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- back-mdb will usually return search entries in entryID order, but may do a dn traversal instead if the count of children is smaller than the count of search filter candidates. The RDNs are sorted in length order, not lexical order. For accesslog, all RDNs are of equal length but if they have trailing zeroes, the generalizedTime normalizer truncates them. Changing their lengths causes accesslog's timestamp-based RDNs to sort in the wrong order. The least intrusive fix is to override the syntax/normalizer for reqStart and reqEnd attributes to not truncate trailing zeroes. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8064] SIGSEGV in monitor-shutdown code
by openldap-its＠openldap.org 01 Sep '22

01 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8064 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9906 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9903] New: Broken link and images in Powered By page
by openldap-its＠openldap.org 31 Aug '22

31 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9903 Issue ID: 9903 Summary: Broken link and images in Powered By page Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: jkirkwood(a)kclinfo.com Target Milestone: --- In the page https://www.openldap.org/powered.html (linked from the phrase 'This site is powered by open source software.' at the bottom of the home page) 1) the link to 'Website Meta Language' is broken - it may have moved to https://thewml.github.io ? 2) the links to the logo images are broken - https://www.openldap.org/icons/logo/wml.gif - https://www.openldap.org/icons/logo/freebsd.gif - https://www.openldap.org/icons/logo/apache.gif I randomly noticed this - not breaking anything I'm aware of, so possibly only a cosmetic issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9516] New: Argon2 configuration parameters with slappasswd
by openldap-its＠openldap.org 23 Aug '22

23 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9516 Issue ID: 9516 Summary: Argon2 configuration parameters with slappasswd Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gilbert.kowarzyk(a)servicenow.com Target Milestone: --- It is currently possible to generate an Argon2 hash using slappasswd as follows: slappasswd -h {ARGON2} -o module-load=pw-argon2 However, I believe that it is currently not possible to provide Argon2 configuration values for parameters "m", "t", and "p" when using slappasswd. If it is currently possible to provide these config parameters when using slappasswd, please add documentation for how to do so. Thanks in advance! -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9889] New: Error while installation Openldap 2.5.9
by openldap-its＠openldap.org 15 Aug '22

15 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9889 Issue ID: 9889 Summary: Error while installation Openldap 2.5.9 Product: OpenLDAP Version: 2.5.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: vmaidarkar(a)gmail.com Target Milestone: --- Hi Team, While installing OpenLDAP v2.5.9 we are getting following error "Clould not locate TLS/SSL package. Error:- checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure:error: Could not locate TLS/SSL package Kindly suggest to resolve this issue. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9891] New: The test case execution time is too long.
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9891 Issue ID: 9891 Summary: The test case execution time is too long. Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- OpenLDAP test cases use a large amount of sleep. As a result, it takes a long time to execute all test cases. Is there any way to shorten the time? -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 9896] New: Error: Could not locate TLS/SSL package
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9896 Issue ID: 9896 Summary: Error: Could not locate TLS/SSL package Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: vmaidarkar(a)gmail.com Target Milestone: --- Created attachment 909 --> https://bugs.openldap.org/attachment.cgi?id=909&action=edit Error: Could not locate TLS/SSL package Hi Team, I'm getting the below error while installing OpenLDAP 2.5.13 on CentOS 7.9 & OpenSSL 1.1.1g & attaching config.log file. checking for openssl/ssl.h... yes checking for SSL_export_keying_material_early in -lssl... no configure: error: Could not locate TLS/SSL package Kindly suggest how to fix this issue. Thanks, Vijay -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9893] New: Unable to create ldap object with same unique value as deleted object
by openldap-its＠openldap.org 08 Aug '22

08 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9893 Issue ID: 9893 Summary: Unable to create ldap object with same unique value as deleted object Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: curtis.ruck+github(a)gmail.com Target Milestone: --- I have a unique overlay that is trying to ensure uniqueness of two attributes, mail and uid. My configdir config for my mdb database: dn: olcOverlay={1}unique objectClass: olcUniqueConfig objectClass: olcOverlayConfig olcOverlay: unique olcUniqueURI: ldap://?mail?sub olcUniqueURI: ldap://?uid?sub structuralObjectClass: olcUniqueConfig If I delete a user, and then go to recreate it, I get this error: msgtype 105, error 19, constraint violation non-unique attributes found with (|(uid=jdoe)(givenName=John)(sn=Doe)(cn=John Doe)(mail=john(a)example.com)(userPassword=<password>)(objectClass=inetOrgPerson)) Somehow I believe the unique index structure is broken. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9890] New: Core is seen while reboot for RHEL_8_4_X86_64
by openldap-its＠openldap.org 03 Aug '22

03 Aug '22

https://bugs.openldap.org/show_bug.cgi?id=9890 Issue ID: 9890 Summary: Core is seen while reboot for RHEL_8_4_X86_64 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: sunil.ece.126(a)gmail.com Target Milestone: --- Hi, I am seeing below core while using openLdap 2.4.59. We are using openLdap in our application as stack to initiate the connection towards ldapServer. Current I am using RHEL_8_4_X86_64. Core is seen whenever system is going for reboot. Let me know if more information is required. (gdb) bt #0 0x00007ff94be7d998 in vtable for {}cxxabiv1::{_}_si_class_type_info () from /lib64/libstdc++.so.6 #1 0x00007ff9520296cc in ManagedObjectList* ManagedObject::findMOListByKey<MOID>(MOID const&) const () from /usr/IMS/current/bin/libMX.so.0 #2 0x00007ff9520287a5 in ManagedObject::findObjectById(MOID const&) const () from /usr/IMS/current/bin/libMX.so.0 #3 0x00007ff952029fa9 in SignalInstaller::signalAction(int, siginfo_t*, void*) () from /usr/IMS/current/bin/libMX.so.0 #4 <signal handler called> #5 memfence_check (ptr=0x7fffffff00000000, size=0x0) at src/tcmalloc.cc:294 #6 0x00007ff94c72f90d in memfence_check_and_free (ptr=<optimized out>, size=size@entry=0x0) at src/tcmalloc.cc:307 #7 0x00007ff94c73dfe4 in free_fast_path (ptr=<optimized out>) at src/tcmalloc.cc:2142 #8 tc_free (ptr=<optimized out>) at src/tcmalloc.cc:2149 #9 0x00007ff949d3b0ce in ldap_int_destroy_global_options () from /lib64/libldap-2.4.so.2 #10 0x00007ff9528cfc96 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #11 0x00007ff94b1d0b0c in __run_exit_handlers () from /lib64/libc.so.6 #12 0x00007ff94b1d0c40 in exit () from /lib64/libc.so.6 #13 0x00007ff94b1ba49a in __libc_start_main () from /lib64/libc.so.6 #14 0x0000000000427b6e in _start () -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9884] New: Document "set" patterns in ACLs
by openldap-its＠openldap.org 25 Jul '22

25 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9884 Issue ID: 9884 Summary: Document "set" patterns in ACLs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd.access(5) man page has this exceptionally unhelpful line where sets are concerned: "The statement set=<pattern> is undocumented yet." Even if it is an experimental feature, it should still be documented on how it is meant to operate. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9885] New: Error while compilation of Openldap 2.5.9
by openldap-its＠openldap.org 22 Jul '22

22 Jul '22

https://bugs.openldap.org/show_bug.cgi?id=9885 Issue ID: 9885 Summary: Error while compilation of Openldap 2.5.9 Product: OpenLDAP Version: 2.5.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: rekha.shivsan(a)gmail.com Target Milestone: --- Created attachment 908 --> https://bugs.openldap.org/attachment.cgi?id=908&action=edit Error while compilation Hi, We are trying to install Openldap v2.5.9. While running the make command we are seeing below error. ./.libs/libldap.so: undefined reference to `BIO_meth_set_read' ./.libs/libldap.so: undefined reference to `BIO_get_data' ./.libs/libldap.so: undefined reference to `BIO_meth_set_write' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_value' ./.libs/libldap.so: undefined reference to `BIO_meth_set_ctrl' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_new_null' ./.libs/libldap.so: undefined reference to `BIO_meth_set_gets' ./.libs/libldap.so: undefined reference to `BIO_meth_set_create' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_ciphersuites' ./.libs/libldap.so: undefined reference to `BIO_meth_set_puts' ./.libs/libldap.so: undefined reference to `BIO_meth_free' ./.libs/libldap.so: undefined reference to `BIO_meth_new' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_push' ./.libs/libldap.so: undefined reference to `EVP_MD_CTX_new' ./.libs/libldap.so: undefined reference to `X509_NAME_get0_der' ./.libs/libldap.so: undefined reference to `BIO_set_init' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_num' ./.libs/libldap.so: undefined reference to `SSL_CTX_up_ref' ./.libs/libldap.so: undefined reference to `OPENSSL_init_ssl' ./.libs/libldap.so: undefined reference to `ASN1_STRING_get0_data' ./.libs/libldap.so: undefined reference to `TLS_method' ./.libs/libldap.so: undefined reference to `EVP_MD_CTX_free' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_options' ./.libs/libldap.so: undefined reference to `SSL_set_ciphersuites' ./.libs/libldap.so: undefined reference to `BIO_meth_set_destroy' ./.libs/libldap.so: undefined reference to `SSL_session_reused' ./.libs/libldap.so: undefined reference to `X509_get_X509_PUBKEY' ./.libs/libldap.so: undefined reference to `OPENSSL_sk_free' ./.libs/libldap.so: undefined reference to `BIO_set_data' ./.libs/libldap.so: undefined reference to `SSL_CTX_clear_options' collect2: error: ld returned 1 exit status Complete error logs are attached " OpenLdap 2.5.9_error.txt". Could you please help to resolve this issue. Thanks. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs