- openldap-bugs - openldap.org

[Issue 7080] post read control in back-config
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7080 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26 (2.6.10): • 8d19c205 by Ondřej Kuzník at 2025-02-19T18:06:29+00:00 ITS#7080 Do not munge path twice • f328965d by Ondřej Kuzník at 2025-02-19T18:06:33+00:00 ITS#7080 Implement pre/postread for modrdn • c667f2ea by Ondřej Kuzník at 2025-02-19T18:15:58+00:00 ITS#7080 Do not reuse back-ldif's stack for controls -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7249 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 993f488e by Ondřej Kuzník at 2025-02-19T17:29:04+00:00 ITS#7249 Let backend_attribute know who's calling it • f2cba910 by Ondřej Kuzník at 2025-02-19T17:29:04+00:00 ITS#7249 Disallow memberof-addcheck when memberof is global -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7080] post read control in back-config
by openldap-its＠openldap.org 19 Feb '25

19 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=7080 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 86d23423 by Ondřej Kuzník at 2024-12-16T17:01:26+00:00 ITS#7080 Do not munge path twice • e5826622 by Ondřej Kuzník at 2024-12-16T17:01:26+00:00 ITS#7080 Implement pre/postread for modrdn • 70d8e22d by Ondřej Kuzník at 2024-12-16T17:01:26+00:00 ITS#7080 Do not reuse back-ldif's stack for controls -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10294] New: Overlay seems to load before schema in folder configuration mode
by openldap-its＠openldap.org 13 Feb '25

13 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10294 Issue ID: 10294 Summary: Overlay seems to load before schema in folder configuration mode Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: pduvax(a)gmail.com Target Milestone: --- In the folder configuration (vs slapd.conf file), the modules seem to be loaded before schema folders files. This makes troubles with memberOf attributeType which is created by the dynlist overlay if missing (cf. the base function "dynlist_initialize" which starts by doing this). As the schema files are not yet loaded, it creates systematically the attributes which then prohibits the load of msuser.ldif schema without raising the error "Duplicate attributeType". I found a workaround by naming the entry of the dynlist overlay olcModuleList cn=z-module{X} while z is alphanumerically after cn=schema. But as it is hazardous, I think that the best way is to load modules after the schema by the code. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10139] back-config discloses existence of entries contrary to ACL
by openldap-its＠openldap.org 10 Feb '25

10 Feb '25

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

1 0

[Issue 10056] New: test069-delta-multiprovider-starttls failures on static builds
by openldap-its＠openldap.org 08 Feb '25

08 Feb '25

https://bugs.openldap.org/show_bug.cgi?id=10056 Issue ID: 10056 Summary: test069-delta-multiprovider-starttls failures on static builds Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kaction(a)disroot.org Target Milestone: --- Hello. I am getting following test error when trying to build `openldap` statically: ``` [nix-shell:/tmp/openldap-static/openldap-2.6.4/tests]$ ./run test069-delta-multiprovider-starttls Cleaning up test run directory leftover from previous run. Running ./scripts/test069-delta-multiprovider-starttls for mdb... running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Waiting 5 seconds for slapd to start... Using ldapadd for context on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Waiting 5 seconds for slapd to start... Using ldapadd to populate server 1... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Using ldapadd to populate server 2... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... Breaking replication between server 1 and 2... Using ldapmodify to force conflicts between server 1 and 2... Restoring replication between server 1 and 2... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Comparing retrieved entries from server 1 and server 2... test failed - server 1 and server 2 databases differ (561) ``` I added line number (561) into error message to pinpoint it more precisely. And here is difference between databases: ``` --- /tmp/openldap-static/openldap-2.6.4/tests/testrun/server1.flt 2023-05-23 22:53:51.000965129 -0400 +++ /tmp/openldap-static/openldap-2.6.4/tests/testrun/server2.flt 2023-05-23 22:53:51.005965136 -0400 @@ -289,13 +289,10 @@ userPassword:: amFq dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com -carLicense: 123-XYZ cn: James A Jones 2 cn: James Jones cn: Jim Jones -description: Amazing description: Bizarre -description: Mindboggling description: Stupendous employeeNumber: 64 employeeType: deadwood @@ -307,7 +304,7 @@ pager: +1 313 555 3923 postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -sn: Surname +sn: Jones telephoneNumber: +1 313 555 0895 title: Mad Cow Researcher, UM Alumni Association uid: jaj ``` Suggestions on what more information I can provide are welcome. You can also try to build `pkgsStatic.openldap` in this nixpkgs [commit](f9e32f61282275eb5fa9064e08bbd0a92d1187de) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10300] New: Add detailed instructions for MRs to "Guidelines for Contributing" page
by openldap-its＠openldap.org 28 Jan '25

28 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10300 Issue ID: 10300 Summary: Add detailed instructions for MRs to "Guidelines for Contributing" 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: smckinney(a)symas.com Target Milestone: --- The current page covers submitting patches but doesn't adequately cover creating merge requests. This provides a barrier for new developers. In addition to clarifying when a change should be submitted with a patch or merge request, it could provide a set of steps including creating a fork, branch, squash, fixup, naming conventions and other info that would be lost on a new contributor. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9245] New: devel/programming needs rewrite
by openldap-its＠openldap.org 28 Jan '25

28 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=9245 Bug ID: 9245 Summary: devel/programming needs rewrite Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The information on the devel/programming web page is at least a decade out of date and needs a complete overhaul. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Issue 10298] New: cannot find DN in memberOf attribute when dynlist overlay contains multiple memberOf definitions
by openldap-its＠openldap.org 22 Jan '25

22 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10298 Issue ID: 10298 Summary: cannot find DN in memberOf attribute when dynlist overlay contains multiple memberOf definitions Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: jan.pekar(a)imatic.cz Target Milestone: --- I'm using dynlist to define multiple static objectClasses (static-oc) to be searched for member attributes and added to memberOf attribute. My configuration is in cn=config, so I defined it using multiple olcDlAttrSet attributes groupOfURLs memberURL member+memberOf@groupOfMembers* groupOfURLs memberURL member+memberOf@groupOfNames* I noticed, that memberOf attribute contains users from both groups (groupOfMembers and groupOfNames) but I can use search operation to only first defined configuration (in above example groupOfMembers) and user membership from groupOfNames groups is not found. Maybe it must be defined in one line but I was not able to find proper syntax. Maybe attribute must be mapped somehow but when it works for first definition, should be working for next one so it is bug? Thank you -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 21 Jan '25

21 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|VERIFIED |CONFIRMED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 21 Jan '25

21 Jan '25

1 0

[Issue 7249] slapd segfault with memberof overlay on frontend db
by openldap-its＠openldap.org 16 Jan '25

16 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=7249 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net --- Comment #21 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/742 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10084] New: Move away from DIGEST-MD5 as a default in the test suite
by openldap-its＠openldap.org 14 Jan '25

14 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10084 Issue ID: 10084 Summary: Move away from DIGEST-MD5 as a default in the test suite Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2 onwards. As such we should update our defaults in a couple of our test scripts for master/2.7 at least. Are SCRAM mechanisms the go-to these days? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10295] New: To compare strings in Java
by openldap-its＠openldap.org 03 Jan '25

03 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10295 Issue ID: 10295 Summary: To compare strings in Java Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JLDAP Assignee: bugs(a)openldap.org Reporter: chetansinha35(a)gmail.com Target Milestone: --- Created attachment 1044 --> https://bugs.openldap.org/attachment.cgi?id=1044&action=edit https://docs.vultr.com/java/java/examples/java/examples/reverse-a-number Java Program to Reversing a number in Java is a common task achieved using loops and arithmetic operations. By repeatedly extracting the last digit of the number with the modulus operator (%) and constructing the reversed number using multiplication and addition, the process is efficient. For example, a while loop can be used to iterate until the number becomes zero, applying reversed = reversed * 10 + number % 10. This logic makes reversing numbers simple and highlights Java's flexibility in handling number manipulation tasks. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 02 Jan '25

02 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #27 from jhaberman(a)gmail.com --- Unfortunately I can still reproduce this with LMDB 0.9.33. Repro: #include <stdlib.h> #include <string.h> #include <stdio.h> #include "lmdb.h" #define VAL(str) {strlen(str), str} #define CHK(st) if (st != 0) { fprintf(stderr, "fail at %d\n", __LINE__); abort(); } int main() { MDB_env* lmdb; int status; status= mdb_env_create(&lmdb); CHK(status); status = mdb_env_open(lmdb, "/tmp/lmdb_repro", 0, 0644); CHK(status); MDB_txn* txn; status = mdb_txn_begin(lmdb, NULL, 0, &txn); CHK(status); MDB_dbi dbi; status = mdb_dbi_open(txn, NULL, MDB_CREATE | MDB_DUPSORT, &dbi); CHK(status); MDB_val k = VAL("key"); MDB_val v1 = VAL("val1"); status = mdb_put(txn, dbi, &k, &v1, MDB_NODUPDATA); CHK(status); MDB_val v2 = VAL("val2"); status = mdb_put(txn, dbi, &k, &v2, MDB_NODUPDATA); CHK(status); return 0; } $ clang -fsanitize=undefined -o repro repro.c mdb.c midl.c $ mkdir /tmp/lmdb_repro $ ./repro Output: --- mdb.c:7654:26: runtime error: member access within misaligned address 0x561c906b85d3 for type 'MDB_page2' (aka 'struct MDB_page2'), which requires 2 byte alignment 0x561c906b85d3: note: pointer points here 00 6b 65 79 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7654:26 in mdb.c:7654:26: runtime error: load of misaligned address 0x561c906b85df for type 'indx_t' (aka 'unsigned short'), which requires 2 byte alignment 0x561c906b85df: note: pointer points here 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7654:26 in mdb.c:7655:3: runtime error: member access within misaligned address 0x561c906b85d3 for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x561c906b85d3: note: pointer points here 00 6b 65 79 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 76 61 6c 31 00 00 00 00 00 00 00 00 [...] --- It appears that some instances of MDB_page2 are not 2-byte aligned. Is this expected? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 01 Jan '25

01 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #26 from jhaberman(a)gmail.com --- I see now that https://github.com/LMDB/lmdb/commit/3947014aed7ffe39a79991fa7fb5b234da47ad1a may have fixed this issue. I was using a version older than this commit. I will try updating and see if that fixes the problem. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8988] Undefined Behavior in slapadd
by openldap-its＠openldap.org 01 Jan '25

01 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=8988 --- Comment #25 from jhaberman(a)gmail.com --- I ran into this UBSAN error today: > third_party/liblmdb/mdb.c:7559:26: runtime error: member access within misaligned address 0x32577fcf7fd3 for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x32577fcf7fd3: note: pointer points here 00 66 6f 6f 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 00 00 00 00 00 00 00 00 62 61 72 00 This corresponds to this line: https://github.com/LMDB/lmdb/blob/da9aeda08c3ff710a0d47d61a079f5a905b0a10a/… > mx->mx_db.md_entries = NUMKEYS(fp); From the bug log I see that there is disagreement over the interpretation of UB. Language lawyering aside, this issue makes it difficult to use LMDB in environments where UBSAN is in use. I also worry about the potential for miscompiles if the compiler is using its own interpretation of UB, and optimizing based on the assumption that UB cannot happen. Is there any way to make LMDB pack its structures less aggressively, so that it will satisfy UBSAN's alignment expectations? Alternatively, there are ways to perform the accesses that make UBSAN happy, but they make the code uglier: https://godbolt.org/z/8EP6cW77s > The code in question is accessing an unsigned short on a 2 byte boundary. I.e., its alignment is correct. UBsan is incorrect here. I cannot speak for the UBSAN authors, but I believe the issue is that, since p->x is equivalent to (*p).x, the dereference of p must be valid, even if x's alignment requirements are looser. To avoid this, you could write *(uint16_t*)((char*)p + offsetof(S, x)), since this avoids actually dereferencing p. But this is obviously much less readable. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10291] New: OpenLDAP matches localhost against local hostname incorrectly
by openldap-its＠openldap.org 18 Dec '24

18 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10291 Issue ID: 10291 Summary: OpenLDAP matches localhost against local hostname incorrectly Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: cmousefi(a)gmail.com Target Milestone: --- When connecting to a localhost LDAP server using TLS, I get this in debug log: # ldapsearch -ZZ -H ldap://localhost/ -d9 <skip...> TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS certificate verification: depth: 1, err: 0, subject: /CN=Test LDAP CA Root, issuer: /CN=Test LDAP CA Root TLS certificate verification: depth: 0, err: 0, subject: /CN=localhost, issuer: /CN=Test LDAP CA Root TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write finished TLS: hostname (1384a4485398) does not match common name in certificate (localhost). TLS: can't connect: TLS: hostname does not match name in peer certificate. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match name in peer certificate Expected behaviour: When connecting to localhost, I would expect the certificate issued to localhost to work. Actual behaviour: Certificate is issued to localhost but ldapsearch matches against local hostname. Here is the server certificate textual presentation subject=CN=localhost Certificate: Data: Version: 3 (0x2) Serial Number: 41:68:1b:be:cb:46:95:45:e7:72:03:8b:6c:b4:75:55:ca:5c:cb:c9 Signature Algorithm: ecdsa-with-SHA256 Issuer: CN=Test LDAP CA Root Validity Not Before: Dec 3 19:04:58 2024 GMT Not After : Sep 2 19:04:58 2034 GMT Subject: CN=localhost Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:f5:f1:f4:7d:56:85:87:b2:98:c9:b2:a2:83:ef: 52:71:01:1e:81:64:9f:64:ec:99:5a:e4:38:63:13: 69:de:09:00:1e:a1:e1:83:4a:c6:58:0d:c0:bb:4f: 36:7f:5a:f7:8f:74:b4:e2:96:06:09:9b:2c:0d:fb: 8c:6d:57:44:2e ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 5A:54:AF:41:E8:A0:EC:3D:28:3D:D6:0D:91:20:97:73:FA:40:AE:9C X509v3 Authority Key Identifier: FB:AF:31:4B:A2:2B:E1:DA:55:6A:3F:EE:D1:A4:74:51:C7:B9:9F:A7 X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, DNS:localhost, DNS:localhost.localdomain Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:46:02:21:00:d4:9a:16:ba:6e:1d:c7:df:bd:5b:3d:56:b7: 0d:ea:aa:a7:7a:7f:d0:c1:ed:77:11:48:e8:aa:b1:6a:a8:ac: 28:02:21:00:d8:41:3d:a0:52:c8:2b:cc:13:34:46:1b:34:dd: 96:87:e5:7c:71:62:50:f3:2d:b1:18:3d:ce:27:34:c9:c4:32 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10292] New: LMDB documentation is unavailable. lmdb.tech domain has expired
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10292 Issue ID: 10292 Summary: LMDB documentation is unavailable. lmdb.tech domain has expired Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: vadim.kovalyov(a)gmail.com Target Milestone: --- LMDB documentation is unavailable. lmdb.tech domain has expired. I can't find the documentation anywhere else. If domain is gone, at least we need to update the openldap website to point to a (new) documentation site. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10289] New: myldap
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10289 Issue ID: 10289 Summary: myldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: cmp(a)tutanota.de Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 7441] cn=config filters ignore {number}
by openldap-its＠openldap.org 27 Nov '24

27 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=7441 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/662 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10218] New: Disabling and re-enabling an asyncmeta database via cn=config leaks memory
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10218 Issue ID: 10218 Summary: Disabling and re-enabling an asyncmeta database via cn=config leaks memory Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- To reproduce - run OpenLDAP with valgrind, and set the olcDisabled attribute of an asyncmeta database to TRUE, then again to FALSE. The connection structures of the database are subsequently shown as leaked. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10249] New: slapo-nestgroup leak with non-nested groups
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10249 Issue ID: 10249 Summary: slapo-nestgroup leak with non-nested groups Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Searching for a member= of a group when no nesting is in place will leak memory. It seems to stem from a few `gi.gi_numDNs` tests that should most likely be against `gi.gi_DNs` instead. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10263] New: ldapmodify error messages should be more helpful when dealing with trailing whitespace
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10263 Issue ID: 10263 Summary: ldapmodify error messages should be more helpful when dealing with trailing whitespace Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Often when copy-pasting, a trailing whitespace can sneak in to a modify LDIF (e.g. "delete: attribute \nattribute: ..."), ldapmodify should emit a different message than: "ldapmodify: wrong attributeType at line x" because that is just not helpful. First off, the line number refers to the one that's usually correct. Emitting an "expecting '%s'" would be a start. Maybe we should even warn/error when an attribute name in a change record contains whitespace, because it's not valid as RFC 2849 grammar only allows ALPHA/DIGIT/'-'/'.'/';' anyway. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10234] New: syncrepl does not reset the retrynum
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10234 Issue ID: 10234 Summary: syncrepl does not reset the retrynum Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- ``` syncrepl retry="5 10 30 +" ``` When replication fails with the above settings, syncrepl retries "10 times at 5 second intervals". Then, the retry count should be reset on the next replication failure. In actual, it does not reset. The behavior is as follows: ``` (first time replication failure) do_syncrepl: rid=001 rc -1 retrying (9 retries left) do_syncrepl: rid=001 rc -1 retrying (8 retries left) (resume replication) (second time replication failure) do_syncrepl: rid=001 rc -1 retrying (7 retries left) do_syncrepl: rid=001 rc -1 retrying (6 retries left) ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs