openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs