- openldap-bugs - openldap.org

[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 10301] New: Use assertion control in lastbind chaining
by openldap-its＠openldap.org 28 Jan '25

28 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=10301 Issue ID: 10301 Summary: Use assertion control in lastbind chaining Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Take a setup with a bunch of consumers tracking lastbind information and replicating this back from the provider. If a client sends a lot of successful binds to it in a very short window, the changes might not have a chance to replicate down so each of these binds has to trigger a new modification to be forwarded. This results in a lot of DB churn and replication traffic that is actually meaningless (the pwdLastChange values before and after each of the mods will be the same). We probably can't avoid having to send something, but the change we send could have an assertion control attached that lets the provider skip it if pwdLastChange>=new_value, saving on all of the additional processing (and additional useless replication traffic). -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[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 9739] New: Undefined reference to ber_sockbuf_io_udp in 2.6.0
by openldap-its＠openldap.org 13 Jan '25

13 Jan '25

https://bugs.openldap.org/show_bug.cgi?id=9739 Issue ID: 9739 Summary: Undefined reference to ber_sockbuf_io_udp in 2.6.0 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: simon.pichugin(a)gmail.com Target Milestone: --- While I was trying to build OpenLDAP 2.6 on Fedora Rawhide I've got the error message: /usr/bin/ld: ./.libs/libldap.so: undefined reference to `ber_sockbuf_io_udp' I've checked commits from https://bugs.openldap.org/show_bug.cgi?id=9673 and found that 'ber_sockbuf_io_udp' was not added to https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/… I've asked on the project's mailing list and got a reply: "That symbol only exists if OpenLDAP is built with LDAP_CONNECTIONLESS defined, which is not a supported feature. Feel free to file a bug report at https://bugs.openldap.org/" https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Hence, creating the bug. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

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

04 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 02 Jan '25

02 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 9886] New: At "sync" logging, nothing shows how long a write op took on consumers
by openldap-its＠openldap.org 17 Dec '24

17 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=9886 Issue ID: 9886 Summary: At "sync" logging, nothing shows how long a write op took on consumers Product: OpenLDAP Version: unspecified 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: --- If sync logging is enabled on a consumer, there's no etime logged which means it is not possible to see how long a write op took on that consumer. This can be useful information to see how the node is performing, particularly if it is a read only node where there will be no general MOD timing logged. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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 10275] New: mdb_load could use a parameter to pass batch size
by openldap-its＠openldap.org 10 Dec '24

10 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10275 Issue ID: 10275 Summary: mdb_load could use a parameter to pass batch size Product: LMDB Version: 0.9.21 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: gkwicker(a)amazon.com Target Milestone: --- Created attachment 1037 --> https://bugs.openldap.org/attachment.cgi?id=1037&action=edit Patch to mdb_load.c in version 0.9.21 mdb_load is very slow when ingesting a large db. The attached patch (0.9.21 but will apply to other versions with modification) allows the user to pass a batch size to be used instead of the default value of 100. Changing the batch size to a larger value improves ingestion speed. I, Gary Wicker, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 10286] New: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case.
by openldap-its＠openldap.org 02 Dec '24

02 Dec '24

https://bugs.openldap.org/show_bug.cgi?id=10286 Issue ID: 10286 Summary: ldap_pvt_gettime may result in "not new enough csn" problems in multi-thread case. Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 971748261(a)qq.com Target Milestone: --- Created attachment 1041 --> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit the log of adding two entry which shows the time sequence. I used openldap as krb5's database, and openldap was deploymented in mirrormode. I tried to add kerberos principals via kadmin.local -q "addprinc -randkey principal. slapd log showed that the entry of kadmin/admin was added earlier than the entry of ossuser. But the csn of kadmin/admin was greater than ossuser. In this case, when the two entry began to sync to the other slapd server, ossuser was ignored because of "csn not new enough" -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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

[Issue 10235] New: Configure without --enable-nestgroup=no enables feature
by openldap-its＠openldap.org 26 Nov '24

26 Nov '24

https://bugs.openldap.org/show_bug.cgi?id=10235 Issue ID: 10235 Summary: Configure without --enable-nestgroup=no enables feature 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: stacey.marshall(a)gmail.com Target Milestone: --- OpenLDAP 2.6.8 configured with --enable-overlays. Some openldap commands output a Duplicate attributeType notice, for example # /sbin/slapcat -b cn=config -H ldap:///???olcTLSCertificateKeyFile=\* | grep olcTLSCertificateKeyFile register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType, 1.2.840.113556.1.2.102 olcTLSCertificateKeyFile: /etc/certs/localhost/host.key Specifying configure option --enable-nestgroup=no prevents nestgroup feature and the message from being displayed. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs