https://bugs.openldap.org/show_bug.cgi?id=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|slapd |liblmdb
Version|2.4.47 |0.9.33
Assignee|bugs(a)openldap.org |hyc(a)openldap.org
Target Milestone|--- |0.9.34
Product|OpenLDAP |LMDB
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
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.
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=edithttps://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.
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.
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.
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.
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.