- openldap-bugs - openldap.org

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 8677] back-sock segfaults on CONTINUE (database sock)
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8677 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 66edd345 by Howard Chu at 2023-11-14T17:02:18+00:00 ITS#8677 back-sock: return error for CONTINUE -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5738] back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 9909] New: slap* tools leak cn=config entries on shutdown
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9909 Issue ID: 9909 Summary: slap* tools leak cn=config entries on shutdown 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: --- slap* tools set up their in-memory cn=config structures but cfb->cb_root is never released on shutdown. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10273] New: Unable to run multiple bitnami openldap containers with common shared volume
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10273 Issue ID: 10273 Summary: Unable to run multiple bitnami openldap containers with common shared volume Product: OpenLDAP Version: 2.6.0 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jvishwanath66(a)gmail.com Target Milestone: --- **Name and Version:** openldap2.6 **What architecture are you using?:** amd64 **What steps will reproduce the bug?** - Add custom ldif files under the /ldifs directory and create another container image named `localhost:32000/custom-openldap` - create a common directory that will be mounted to all the ldap containers (`/root/openldap`) Create multiple container images which are mounted to the same directory (`/root/openldap`) using the following command - Add custom ldif files under the /ldifs directory and create another container image named localhost:32000/custom-openldap - create a common directory that will be mounted to all the ldap containers (`/root/openldap`) Create multiple container images which are mounted to the same directory (`/root/openldap`) using the following command ``` docker run -d -e BITNAMI_DEBUG="true" -e LDAP_ADMIN_USERNAME="superuser" -e LDAP_BINDDN="cn=ldap_bind_user,ou=people,dc=example,dc=com" -e LDAP_ENABLE_TLS="no" -e LDAP_EXTRA_SCHEMAS="cosine,general-acl,my-permissions,my-roles,ppolicy,nis,inetorgperson" -e LDAP_ROOT="dc=example,dc=com" -e LDAP_SKIP_DEFAULT_TREE="yes" -e LDAP_URI="ldap://ldap-server-service.my-namespace.svc.cluster.local" -e USER_DESCRIPTION_MAX_LEN="100" -e USER_FIRST_AND_LAST_NAME_MAX_LEN="100" -e USER_NAME_MAX_LEN="100" -e LDAP_ADMIN_PASSWORD="admin123" -e LDAP_READONLY_USER_PASSWORD="admin123" -e proxyBindPassword="" -v /root/openldap:/bitnami/openldap localhost:32000/custom-openldap ``` - List container images using the docker ps command: ``` docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f77ef5455f5f localhost:32000/custom-openldap "/opt/bitnami/script…" 2 minutes ago Up 2 minutes 1389/tcp, 1636/tcp upbeat_raman 9cccd41f02d2 localhost:32000/custom-openldap "/opt/bitnami/script…" 17 minutes ago Up 17 minutes 1389/tcp, 1636/tcp nostalgic_antonelli 5434761c9281 localhost:32000/custom-openldap "/opt/bitnami/script…" 23 minutes ago Up 23 minutes 1389/tcp, 1636/tcp objective_mayer ca40ef1a68a2 localhost:32000/custom-openldap "/opt/bitnami/script…" 26 minutes ago Up 26 minutes 1389/tcp, 1636/tcp angry_margulis ``` - Execute the following ldapsearch command in all the containers ``` ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 ``` **What is the expected behavior?** The expected behavior is that ldapsearch should work on all the pods correctly **What do you see instead?** Ldapsearch is working on one container image whereas on other container images, we see the following error ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` I wanted to know whether it is feasible/possible to use the same mount point for multiple openldap containers. **Additional information** Following is the list of container images ``` $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f77ef5455f5f localhost:32000/custom-openldap "/opt/bitnami/script…" 2 minutes ago Up 2 minutes 1389/tcp, 1636/tcp upbeat_raman 9cccd41f02d2 localhost:32000/custom-openldap "/opt/bitnami/script…" 17 minutes ago Up 17 minutes 1389/tcp, 1636/tcp nostalgic_antonelli 5434761c9281 localhost:32000/custom-openldap "/opt/bitnami/script…" 23 minutes ago Up 23 minutes 1389/tcp, 1636/tcp objective_mayer ca40ef1a68a2 localhost:32000/custom-openldap "/opt/bitnami/script…" 26 minutes ago Up 26 minutes 1389/tcp, 1636/tcp angry_margulis ``` And following is the ldapsearch output on all the containers: f77ef5455f5f ``` $ docker exec -it f77ef5455f5f bash $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` 9cccd41f02d2: ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error text: internal error # numResponses: 1 ``` 5434761c9281: ``` $ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 # extended LDIF # # LDAPv3 # base <dc=example, dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # example.com dn: dc=example,dc=com objectClass: top objectClass: domain dc: example # groups, example.com dn: ou=groups,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: groups ``` - ca40ef1a68a2 (Somehow LDAP bind failed on this container, there seems to be some environmental issue) ```$ ldapsearch -H ldap://localhost:1389 -b "dc=example, dc=com" -D "cn=superuser,dc=example,dc=com" -w admin123 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)``` -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 --- Comment #13 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Hi Ondřej, your patch worked for me, TLS handshake timeout was properly applied in all (synchronous) combinations of: * unreachable network / unresponsive service * OpenSSL / GnuTLS * ldaps:// / ldap:// + StartTLS Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9042] loglevel setting that allows seeing attribute values for MOD operations
by openldap-its＠openldap.org 22 Oct '24

22 Oct '24

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

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 21 Oct '24

21 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 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 #12 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Hi Maxine/Allen, can you try MR!727 linked below and tell us if this fixes your issues? https://git.openldap.org/openldap/openldap/-/merge_requests/727 It would be helpful if people setting LDAP_BOOL_CONNECT_ASYNC could also confirm this doesn't cause regressions for them. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8047] TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by openldap-its＠openldap.org 17 Oct '24

17 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8047 --- Comment #11 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Hi, I understand that fixing timeouts during SSL handshake is not possible in the current state of SSL libraries, but I would like to report what seems to me like a regression in OpenLDAP 2.5/2.6 On my RHEL7 and RHEL8 systems ( OpenLDAP 2.4 built with OpenSSL), I was somehow not able to reproduce the issue mentioned here: NETWORK_TIMEOUT works for ldaps:// URLs and TIMEOUT works for ldap:// URLS + StartTLS In OpenLDAP 2.4.49 + GnuTLS (Ubuntu Focal), NETWORK_TIMEOUT does not work for ldaps:// URLs but TIMEOUT works for StartTLS However starting with 2.5 (Debian Bookworm, RHEL9, and also reproduced with a source build of OPENLDAP_REL_ENG_2_6 as well), I observe a different behavior, affecting both GnuTLS and OpenSSL: The following command enters the CPU loop reported in ITS#10141, and never times out > ldapsearch -H ldaps://stuck-slapd -o network_timeout=5 The following command still times out as expected > ldapsearch -H ldap://stuck-slapd -Z -o timeout=5 To clarify, users of OpenLDAP + OpenSSL will start noticing a large CPU spike that does not timeout, instead of a clean timeout, when a LDAP server becomes unreachable for non-TCP reasons. For instance: I discovered this issue while investigating an outage following a storage issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9220 Bug ID: 9220 Summary: Rewrite Bind and Exop result handling Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Bind and Exop result handling needs a rewrite so it is no longer a special case for overlays. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 9881] New: Ability to track last authentication for database objects
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9881 Issue ID: 9881 Summary: Ability to track last authentication for database objects 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: --- For simple binds, we have the ability to track the last success via the lastbind functionality (pwdLastSuccess attribute). However this doesn't allow one to see when an object that exists in a database last authenticated via SASL. It would be useful to add similar functionality for SASL binds. This can be useful information that allows one to tell if an object is being actively authenticated to (generally, users and system accounts, etc). Obviously if something is directly mapped to an identity that doesn't exist in the underlying DB, that cannot be tracked. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9640] New: ACL privilege for MOD_INCREMENT
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9640 Issue ID: 9640 Summary: ACL privilege for MOD_INCREMENT Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm using LDAP write operations with MOD_INCREMENT with pre-read-control for uidNumber/gidNumber generation. I'd like to limit write access to an Integer attribute "nextID" to MOD_INCREMENT, ideally even restricting the de-/increment value. (Uniqueness is achieved with slapo-unique anyway but still I'd like to avoid users messing with this attribute). IMHO the ideal solution would be a new privilege "i". Example for limiting write access to increment by one and grant read access for using read control: access to attrs=nextID val=1 by group=... =ri Example for decrementing by two without read: access to attrs=nextID val=-2 by group=... =i -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9356 Issue ID: 9356 Summary: Add list of peerSIDs to consumer cookie to reduce cross traffic Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If we add a list of peersids to the cookie, each consumer can tell the providers who else the consumers talk to and then the provider can omit sending updates to that consumer, originating from those peers There's some special handling needed if a connection dies If a consumer loses one of its peer connections, and after N retries is still not connected, it should send a new cookie to its remaining peers saying "here's my new peer list" with the missing one removed. Likewise, if a retry eventually connects again, it can send a new cookie again Make that peer list reset configurable in the syncrepl config stanza. This can help account for end admin knowledge that some links may be more or less stable than other ones. The idea here is that if one of your other peers can still see the missing peer, they can start routing updates to you again It should abandon all existing persist sessions and send a new sync search with the new cookie to all remaining peers For consumer side, also means adding the sid for a given provider into the syncrepl stanza to save on having to try and discover the peer sid. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Bug 9219] New: Streamline tool API for 2.5
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9219 Bug ID: 9219 Summary: Streamline tool API for 2.5 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The current tool API is a mess and needs fixing for 2.5. This affects things like slapacl (The fix for bug#7920 was a kludge to deal with this, needs revisiting). -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Issue 7920] MDB_BAD_RSLOT while executing slapacl
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7920 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9219 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9080] Feature request: support DNS SRV lookups in ldap.conf
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

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

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=7027 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7027] [PATCH] Implement priority/weight for DNS SRV records
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7027 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8204 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8204] rfc2782 shuffle implementation doesn't treat equal-weight records equally
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8204 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6462 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=6462 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=5919 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9080] Feature request: support DNS SRV lookups in ldap.conf
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9080 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** This issue has been marked as a duplicate of issue 5919 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=5919 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gray(a)nxg.name --- Comment #33 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9080 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=6462 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8610 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8610 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6462 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10267] New: stats loglevel reduction
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10267 Issue ID: 10267 Summary: stats loglevel reduction Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: chris.paul(a)rexconsulting.net Target Milestone: --- In high volume situations, stats logging of all transactions is not worth the cost of disk space and disk iops. However, turning logging off altogether (loglevel 0) results in no visibility for errors. It would be very useful to be able to log errors only. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10259] New: Wrong RID sends when using syncrepl provider
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10259 Issue ID: 10259 Summary: Wrong RID sends when using syncrepl provider Product: OpenLDAP Version: 2.6.8 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: florent.david(a)gmail.com Target Milestone: --- When using a custom syncrepl consumer bind to an OpenLDAP v2.6.8 provider and it quickly appears than this provider sends to our consumer a cookie with a Replica ID different from the original one. In the logs below, we clearly see a refreshAndPersist synchronization initialized whith a RID with value 606. After a while, on the same connection, OpenLDAP syncrepl provider sends a new cookie with RID=612 66f2ea7d.3b1f8427 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: got a persistent search with a cookie=rid=606,csn=20240924154708.334351Z#000000#000#000000 66f2ea7d.3b1fafc0 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_findbase: searching 66f2ea7d.3b20ca28 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: registered persistent search 66f2ea7d.3b20e5bf 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: no change, skipping log replay 66f2ea7d.3b20ed6a 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: nothing changed, finishing up initial search early 66f2ea7d.3b20f874 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_sendinfo: refreshDelete cookie= 66f2ea7d.3b229483 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_search_response: detaching op 66f2ed56.12f82965 0x7fa816dfe6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164822.305028Z#000000#000#000000 66f2ed56.12fa5399 0x7fa7f58fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164822.305028Z#000000#000#000000 66f2ed8d.053d71e3 0x7fa8165fd6c0 conn=92750 op=1 syncprov_qresp: set up a new syncres mode=4 csn=20240924164917.069189Z#000000#000#000000 66f2ed8d.05405bb4 0x7fa7ed3fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a new cookie=rid=612,csn=20240924164917.069189Z#000000#000#000000 Is it a normal behaviour ? Should consumer checks the Replica ID sends by OpenLDAP before storing it ? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10269] New: slap-constraint: Refactor to use a sorted array
by openldap-its＠openldap.org 15 Oct '24

15 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10269 Issue ID: 10269 Summary: slap-constraint: Refactor to use a sorted array Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As noted in the comments for slapo-constraint: /* * Linked list of attribute constraints which we should enforce. * This is probably a sub optimal structure - some form of sorted * array would be better if the number of attributes constrained is * likely to be much bigger than 4 or 5. We stick with a list for * the moment. */ -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=6198 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ryan(a)openldap.org --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- *** Issue 9211 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9204 Bug ID: 9204 Summary: slapo-constraint allows anyone to apply Relax control Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- slapo-constraint doesn't limit who can use the Relax control, beyond the global limits applied by slapd. In practice, for many modifications this means any configured constraints are advisory only. In my opinion this should be considered a bug, in design if not implementation. I expect many admins would not read the man page closely enough to realize the behaviour does technically adhere to the letter of what's written there. Either slapd should require manage privileges for the Relax control globally, or slapo-constraint should perform a check for manage privilege itself, like slapo-unique does. Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4: > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Note that the user: > > - must have enough privileges to do it (manage) > > - must inform the DSA that intends to violate the constraint (by using > the control) but such privileges are currently not being required. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Issue 6462] DNS SRV records: ldaps ???
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

1 0

[Issue 5919] URI syntaxe (ldap:///dc=my%2cdc=domaine)
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

1 0

[Issue 9042] loglevel setting that allows seeing attribute values for MOD operations
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

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

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • af4dfade by Quanah Gibson-Mount at 2024-10-04T21:53:57+00:00 ITS#7400 - Fix exattr to exattrs option -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7982] Add tls cipher suite, protocol to ldapsearch debug logging
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7982 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 139944ac by Ondřej Kuzník at 2024-09-27T14:21:20+01:00 ITS#7982 Log TLS proto+cipher suite on client side -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7400] Memberof and Syncrepl incompatibility
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=7400 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • d1987e00 by Quanah Gibson-Mount at 2024-07-31T22:50:32+00:00 ITS#7400 - Fix exattr to exattrs option -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10247] New: libldap should reject unrecognized critical URL extensions
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10247 Issue ID: 10247 Summary: libldap should reject unrecognized critical URL extensions Product: OpenLDAP Version: 2.6.8 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently the only URL extension libldap recognizes is StartTLS. It ignores anything else, but it is not supposed to ignore them if they're marked critical. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10242] New: Improve syncrepl client traceability
by openldap-its＠openldap.org 04 Oct '24

04 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10242 Issue ID: 10242 Summary: Improve syncrepl client traceability 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: --- The o_log_prefix in do_syncrepl()'s internal operation could be tweaked to contain the rid=..., that would significantly improve syncrepl traceability in the server logs and gdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL
by openldap-its＠openldap.org 03 Oct '24

03 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9303 Issue ID: 9303 Summary: Add support for WolfSSL as an alternative to OpenSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an alternative to OpenSSL. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 8673] Need duration logging for sync ops
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8673 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ondřej Kuzník <ondra(a)mistotebe.net> --- *** This issue has been marked as a duplicate of issue 9886 *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10262] New: Feature request: configurable memory alignment of LMDB keys and values
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10262 Issue ID: 10262 Summary: Feature request: configurable memory alignment of LMDB keys and values Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: sascha(a)brawer.ch Target Milestone: --- When creating an LMDB table, it would be nice if an application could request how its keys and values will be aligned in memory. Currently, LMDB seems to gives 2-byte alignment; see LMDB issue 10260. On most non-Intel CPUs, unaligned reads will cause SIGBUS errors, so any data with 32-bit or 64-bit values has to be accessed in multiple 16-bit chunks (which is inefficient), or copied out of LMDB-mapped memory into a custom, properly aligned buffer (which is inefficient, too). To prevent such performance degradation, it would be nice if applications could request alignment of keys and/or values to 8-byte boundaries. Then, LMDB data would have the same alignment guarantees as malloc(). The Linux kernel has a nice description of alignment: https://www.kernel.org/doc/html/latest/core-api/unaligned-memory-access.html Even on Intel CPUs, being able to specify alignment would be useful. For example, AVX-512 benefits from data being aligned to 64-byte boundaries. If an application could request 64-byte alignment for a given table, its values could be loaded direclty into AVX-512 registers. This would be useful for applications whose tables contain bitvectors or other data suitable for SIMD proceesing. https://www.intel.com/content/www/us/en/developer/articles/technical/data-a… Of course, padding comes at a cost. It increases storage space and reduces cache effectiveness. It would be wasteful to align each key and value in every table to some boundary. Hence the suggestion to make this configurable per table, perhaps with additional flags for mdb_dbi_open(). One could argue that memory alignment is out of scope for LMDB, leaving it up to applications to deal with misalignments. However, because of the cost of workarounds, it would make LMDB (significantly) less efficient than it could be, even on Intel CPUs. Thus, many thanks for considering this feature request. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10260] New: Document alignment of MDB_val.mv_data
by openldap-its＠openldap.org 02 Oct '24

02 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10260 Issue ID: 10260 Summary: Document alignment of MDB_val.mv_data Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: sascha(a)brawer.ch Target Milestone: --- In lmdb.h, could the documentation for MDB_val talk about alignment of mv_data? For example, is the key guaranteed to be aligned to an 8-byte boundary if a table got created with MDB_INTEGERKEY? What about values in MDB_INTEGERDUP tables? Can database values be directly loaded into SIMD registers (of what width?) without first copying the data to an aligned location? On some processor architectures, unaliged reads lead to bus errors; therefore, it would help programmers to know whether LMDB makes any alignment guarantees. Even if clients cannot assume anything, it would be good if LMDB’s public API documentation could state so. Many thanks for documenting this! Just adding 1 or 2 sentences to the MDB_val section in lmdb.h would be enough. — Sascha Brawer, sascha(a)brawer.ch -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9002] Add option to slapcat to honor rtxnsize setting
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9002 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- It's a tradeoff. If you can't accomodate the potential DB size increase, you must stop slapd. If you can't tolerate stopping slapd, you have to provide enough disk space. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9022] Force slapadd to rewrite all entryCSN values
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9022 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Add it as a new option under -o flag -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9002] Add option to slapcat to honor rtxnsize setting
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9002 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |documentation --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Document best practices for consistent backups, namely: Stop slapd, slapcat, start slapd, perhaps a dedicated server for this purpose. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8757] RFE: let slapd MMR instances vote primary master
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8757 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |3.0.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8673] Need duration logging for sync ops
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=8673 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8617] Seg-fault while using meta database and rwm overlay together
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

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

1 0

[Issue 10261] New: draft-behera-ldap-password-policy - evolution pwdAccountDisabled
by openldap-its＠openldap.org 01 Oct '24

01 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=10261 Issue ID: 10261 Summary: draft-behera-ldap-password-policy - evolution pwdAccountDisabled Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Hello, For information, I tried to send a mail at: draft-behera-ldap-password-policy(a)ietf.org first, but I get a: Recipient address rejected: User unknown I'd like to propose an evolution for the current version of draft-behera-ldap-password-policy. Indeed, in the specification, there is the notion of locked or blocked account, with the presence of pwdAccountLockedTime, preventing users from authenticating. However: * any account with sufficient privileges can modify the userPassword * when he does so, the pwdAccountLockedTime is removed This behaviour is advisable most of the time. But sometimes we need a more restrictive policy. The goal of this evolution is to propose an alternate behaviour where the "disabling attribute" is never removed unless asked explicitely, and where userPassword cannot be modified until the "disabling attribute" is present. This attribute could be named pwdAccountDisabled. Here is the proposed evolution: 4.1.1. Password Validity Policy ... A password cannot be used to authenticate while the corresponding account has been disabled. 4.2.8. Disabled account A password cannot be changed while the password owner has been disabled. While doing so, the LDAP directory should send a Constraint violation (19) error code with additional info: Account is disabled. 5.3.12. pwdAccountDisabled This attribute holds the time that the user's account was disabled. A disabled account means that the password may no longer be used to authenticate and none can change the userPassword until it is disabled. ( 1.3.6.1.4.1.42.2.27.8.1.33 NAME 'pwdAccountDisabled' DESC 'The time an user account was disabled' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation ) Thanks in advance for your consideration. Of course, it is opened to discussion, and maybe can I help a little for the implementation. Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8611] Option to disable SSL renegotiation entirely
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8611 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |--- Summary|Option to block SSL |Option to disable SSL |renegotation after X |renegotiation entirely |attempts | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Likely not needed for OpenLDAP, option would be to disable renegotiation entirely. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

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

1 0

[Issue 8491] slapdelete test needed
by openldap-its＠openldap.org 24 Sep '24

24 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8491 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |--- Resolution|--- |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- already covered by slapmodify test007 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #18 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, tg(a)debian.org wrote: >AIUI, this should likely be something like: … make that… +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, +- LDAP_PVT_INTTYPE_CHARS(long), ++ LDAP_PVT_INTTYPE_CHARS(long long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); … of course. (It’s 03:04 in the night, and re-reading those comments from above was not effortless.) bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #17 from tg(a)debian.org <tg(a)debian.org> --- On Sat, 21 Sep 2024, openldap-its(a)openldap.org wrote: >https://bugs.openldap.org/show_bug.cgi?id=8890 >I didn't understand Howard's comment ('the unconditional use of "long long" […] Looking at it *again*, with some years of distance, I *think* I now see what Howard’s barely comprehensible and rather rude comments were meant to point out. I did not see it at that time because ⓐ I was trying, and, as a nōn-English-native speaker, failing to puzzle out what he was saying, and ⓑ the OpenLDAP code’s use of abstractions here has massively reduced its legibility. + keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); I think the first line of that is the point of critique. On repeat reading, it looks like it tries to figure out how many bytes are needed to represent a long, then allocates a buffer sized by this. As I correctly pointed out, this is a separate issue. However, Howard rejected both the immediate fix of printing wrong data RIGHT NOW (and likely truncating that at some point in the future) and this follow-up bug to address that truncation. AIUI, this should likely be something like: +- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); ++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) ); + keys[0].bv_len = snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); Of course, someone who actually knows wth LDAP_PVT_INTTYPE_CHARS is needs to ensure that it DTRT for an argument of “long long” first. bye, //mirabilos -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 20 Sep '24

20 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8890 --- Comment #16 from Ryan Tandy <ryan(a)openldap.org> --- Debian and Ubuntu have both switched their remaining 32-bit architectures, except for i686, to 64-bit time_t. The change is in Ubuntu 24.04 (already released) and Debian 13/trixie (not yet released). Steve Langasek committed this distro patch: https://salsa.debian.org/openldap-team/openldap/-/blob/2a8f9240b9b6fd577d91… It's mostly the same as what was previously proposed in this ITS (changing %ld format specifiers to %lld), and unfortunately contains the same smbk5pwd bug that was already commented on. I didn't understand Howard's comment ('the unconditional use of "long long" instead of "long" will break on machines where "long long" is not 64 bits'). My understanding is C specifies "long long" to be at least 64 bits, and I'm not aware of any existing systems (yet) where "long long" is 128 bits - is it more of a futureproofing concern? Casting to long long and formatting with %lld seems to be the generally accepted solution in the broader community. If that's not acceptable, maybe scripting configure to generate a PRI_TIME_T format specifier? Steve's patch comment mentions an assertion failure in test046-dds on 32-bit ARM: servers/slapd/overlays/dds.c:422: dds_op_add: Assertion `bv.bv_len < sizeof( ttlbuf )' failed. I have not reproduced it myself (I don't have ARM hardware, and it isn't happening for me on x86). I note that the assertion ttl <= DDS_RF2589_MAX_TTL just above did not fail; but that does not rule out corruption of either the 64-bit value (could be negative) or the 32-bit quantity read by snprintf. I haven't figured out what actually happened here, but it's irritating me. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7981] Feature request: Crypt scheme in pwdPolicy
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=7981 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- We can't simply add this to the pwdPolicy objectclass since that is a standardized class. Also the values of crypt schemes are server specific, not standardized at all. A solution for us would be to define an OpenLDAP-specific subclass of the pwdPolicy class, and add whatever we need to in there and use it going forward. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6938] Windows IPv6 support
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6938 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs(a)openldap.org |mhardin(a)symas.com Ever confirmed|0 |1 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Matt to confirm slapd can listen to IPv6 on Windows, and that the ldap client tools can talk to slapd over IPv6 on windows. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6765] SASL support of "Verify Credentials" extop
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6765 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Server-side support of |SASL support of "Verify |"Verify Credentials" extop |Credentials" extop -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6942] updateref config is inadequate
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6942 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6531] Modify updateref to generate referrals on the backend
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6531 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10217] New: autoca should support more key types
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=10217 Issue ID: 10217 Summary: autoca should support more key types Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Currently autoca only creates certificates using RSA keypairs. It should at least have an option to use Elliptic Curve keypairs. It probably also needs options to specify other signature algorithms other than the default of SHA256. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9813 Issue ID: 9813 Summary: Incompatibility between remoteauth and ppolicy overlays 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, We are planning to use OpenLDAP as a proxy for some users in our Active Directory servers, using remoteauth overlay. We want this OpenLDAP instance to also implement an account lockout policy, preventing the lockout on our internal Active Directory servers. But there seems to be an incompatibility between remoteauth and ppolicy overlays : remoteauth won't remote authenticate a user if local userPassword attribute exists, while ppolicy overlay needs this attribute. Could there be a configuration parameter in ppolicy to allow lockout checks/modifications (which seemed to be the default behavior of OpenLDAP before ITS#7089) ? I can provide a patch if allowed. Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter 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: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 8476] slapo-constraint: info per constraint_attribute
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8476 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Seems like a good idea. For constraints where no custom message was provided, we could return the constraint number to provide a pointer to which constraint was triggered. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9652] New: Add "tee" capability to load balancer
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9652 Issue ID: 9652 Summary: Add "tee" capability to load balancer Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- This is a request for an enhancement that would add a "tee" or "fan-out" capability to load balancer, where received operations are sent to two or more destinations simultaneously. The primary goal or the enhancement is to make it possible to keep multiple independent and likely dissimilar directory systems in lock-step with each other over hours, days, or possibly even weeks. The enhancement would not necessarily need to include a mechanism for converging the target systems should they become out of sync. This is not intended to be a replication solution, rather it is viewed more as a "copy" solution intended to be used for specific short-term tasks that need multiple directory systems to be exactly synchronized but where replication is not desirable or even possible. At least two uses come to mind: 1. Test harnesses, evaluating side-by-side operation of separate directory systems over time 2. Directory system transition validation harnesses 3. (maybe) Part of a test harness to record or replay LDAP workloads * Other uses? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9667] New: 2.6 to 2.7 upgrade documentation
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9667 Issue ID: 9667 Summary: 2.6 to 2.7 upgrade documentation 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: --- Need to document any upgrade information for going from 2.6 to 2.7 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6198] Authorization for extensions
by openldap-its＠openldap.org 12 Sep '24

12 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=6198 --- Comment #6 from Ondřej Kuzník <ondra(a)mistotebe.net> --- A few open questions I can't resolve yet: - Do we rely on OID macros from schema or let slap_control/load_extop2 register it? The suggestions above tend to prefer OID macros but they have to be defined in the schema (there's only one) and they're currently case-sensitive For controls: - Do we want to be able to use ACLs to turn non-critical controls to ignored? - Do we want to be able to use ACLs to refuse control combinations? - Apart from the 'to' clause, do we want it allowed in the 'by' clause as well (when would it be useful? There's control combinations, anything else?) I'll start with "no" to all 3 of the above for now. As for combination with other specifiers (especially for exops), ACL checks are issued with the operation and an entry right now, they do make sense in that scope so password modify/DDS refresh should be in the clear. Other extops are more of a problem: - whoami: technically there is a DN but it doesn't have to correspond to an entry - verify credentials: tricky, since it's processed as a bind - cancel: abandon can't be restricted, so probably the same - turn: no idea - ChainedRequest: even less of one Probably happy for those to be impossible to restrict in this way, at least for now. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8905] Client side debug log should include timestamps
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8905 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |gnoe(a)symas.com -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7982] Add tls cipher suite, protocol to ldapsearch debug logging
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=7982 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9398] New: Stale accesslog cookie due to unclean shutdown
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9398 Issue ID: 9398 Summary: Stale accesslog cookie due to unclean shutdown Product: OpenLDAP Version: 2.4.56 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db. Depending on the syncprov overlay checkpoint settings (usually no checkpointing is enabled on the accesslog db) this can cause the system to refuse engage in replication at startup. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Issue 8943] back-mdb: speed up parallel add/delete
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=8943 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED --- Comment #6 from Howard Chu <hyc(a)openldap.org> --- One major problem here is that overlays assume they all execute in the same thread for the duration of an operation. Putting the response in the worker thread would break overlay response callbacks. It would be quite a lot of refactoring to make overlays thread-independent, and that's not going to happen soon. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10255] New: OpenLDAP should leak the SSL ctx and not try to free it in an atexit() handler
by openldap-its＠openldap.org 03 Sep '24

03 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=10255 Issue ID: 10255 Summary: OpenLDAP should leak the SSL ctx and not try to free it in an atexit() handler Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- As mentioned in the subject, OpenLDAP incorrectly handles OpenSSL in its destructor. Сomprehensive information can be found here (along with a possible solution): https://github.com/openssl/openssl/issues/25294 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9796] New: Deprecate GnuTLS support
by openldap-its＠openldap.org 20 Aug '24

20 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=9796 Issue ID: 9796 Summary: Deprecate GnuTLS support Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due to the license objections at the time that the Debian project had for the OpenSSL license. Since that time, Debian has reclassified OpenSSL as a core library and the OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and later under the Apache License v2. Thus there is no longer a reason to maintain support for GnuTLS and given the long standing concerns over the security and quality of the GnuTLS bridge in addition to the extra cost of maintaining that code, it should be marked as deprecated and removed in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10252] New: Unable to fetch groups and users at duo admin panel for enabling MFA for Ldap users
by openldap-its＠openldap.org 14 Aug '24

14 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10252 Issue ID: 10252 Summary: Unable to fetch groups and users at duo admin panel for enabling MFA for Ldap users Product: OpenLDAP Version: 2.5.18 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ajay41.kumar(a)airtel.com Target Milestone: --- Hi Team, I got stuck at configuring openldap server with member of overlay for groups with below requirement.We are trying to enable Multifactor authentication using duo auth proxy & duo admin panel configuration for ldap users. Ldap server is getting synced successfully with Duo admin portal but groups and users details not fetching at duo admin portal. Duo support team mentioned to change ldap configuration as mention article. Can someone help me, How i can make these changes. https://duo.my.site.com/s/article/4529?language=en_US -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10251] New: wrong type passed to getsockname
by openldap-its＠openldap.org 13 Aug '24

13 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10251 Issue ID: 10251 Summary: wrong type passed to getsockname 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: --- New compilers don't allow passing sockaddr_storage * to getsockname() so clients/tools/common.c no longer compiles. Fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10250] New: syncrepl_diff_entry assumes attributes come in the same order
by openldap-its＠openldap.org 13 Aug '24

13 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10250 Issue ID: 10250 Summary: syncrepl_diff_entry assumes attributes come in the same order 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: --- When trying to diff an entry, syncrepl_diff_entry explicitly assumes attribute come in the same order. That's not always the case and could cause it to report a spurious rewrite of the attribute. Normally this is ok, unless the rewrite itself (not) occurring has other side-effects, when it could cause issues. (e.g. a DB with memberof inconsistencies being mysteriously repaired in some scenarios, which is how it was found). -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10244] New: Fix pointer type
by openldap-its＠openldap.org 10 Aug '24

10 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10244 Issue ID: 10244 Summary: Fix pointer type Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: zanaviska(a)tutanota.com Target Milestone: --- Created attachment 1026 --> https://bugs.openldap.org/attachment.cgi?id=1026&action=edit passed temprorary variable Hi I am trying to add MINGW support for another project, But each time I get an error ``` mdb.c:3921:76: error: passing argument 3 of 'GetOverlappedResult' from incompatible pointer type [-Wincompatible-pointer-types] note: expected 'LPDWORD' {aka 'long unsigned int *'} but argument is of type 'ssize_t *' {aka 'long long int *'} ``` So I came up with a fix for your software, with I attach in attachment -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10243] New: Looking to get account on OpenLDAP Gitlab
by openldap-its＠openldap.org 06 Aug '24

06 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10243 Issue ID: 10243 Summary: Looking to get account on OpenLDAP Gitlab Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ak.openldap(a)anroet.com Target Milestone: --- I'm trying to open an account on Gitlab. The purpose for having an account on gitlab is so that I can start the process of building a docker image for use in our Production K8s environment. Currently, I can only find docker images for version 2.4 and the admission controllers in out production k8s clusters isn't having none of that. I'm attempting to create an account using the following email address: ak.openldap(a)anroet.com -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10246] New: Impossible to add integerOrderingMatch ordering rule for integer syntax attribute
by openldap-its＠openldap.org 02 Aug '24

02 Aug '24

https://bugs.openldap.org/show_bug.cgi?id=10246 Issue ID: 10246 Summary: Impossible to add integerOrderingMatch ordering rule for integer syntax attribute Product: OpenLDAP Version: 2.5.18 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: thierryblaise(a)hotmail.com Target Milestone: --- Hi everyone, As I don't know anymore where to search, I'm trying here: I added a custom objectClass to my v2.5.18 openLDAP deployment schema, and in that schema, there's an attribute of type integer that I need to be able to search for with filter "<=" and ">=". To that end, and to my knowledge and following documentation (https://www.openldap.org/doc/admin25/schema.html#Attribute%20Type%20Specifi…), I need to declare an ordering matching rule in attribute definition of the schema. However, when I do that with the following olcAttributeTypes definition : olcAttributeTypes: ( 1.3.6.1.4.1.xxx.x.x.xxx NAME 'last-modified' DESC 'Object Last Modified Time' ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) and try to import the ldif containing this definition, the following error appears: modifying entry "cn={5}clients,cn=schema,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: olcAttributeTypes: AttributeType inappropriate matching rule: "integerOrderingMatch" I tried with all documented OrderingMatch rules in case, but same error modulo name of OrderingMatch rule. Basic schemas only have been imported (core, nis, cosine, inetOrgPerson) Any idea what I do wrong? -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10245] New: mdb_env_set_maxdbs signature appears incorrect
by openldap-its＠openldap.org 30 Jul '24

30 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10245 Issue ID: 10245 Summary: mdb_env_set_maxdbs signature appears incorrect Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: bchik(a)meta.com Target Milestone: --- The current signature for mdb_env_set_maxdbs: int mdb_env_set_maxdbs(MDB_env *env, MDB_dbi dbs); The documentation says the second parameter is intended to be the maximum number of databases, however, the parameter is typed as a DB handle. This appears to work because MDB_dbi is typedef'd to an unsigned int. I believe the intended signature would be: int mdb_env_set_maxdbs(MDB_env *env, unsigned int dbs); -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10241] New: Crash in mdb_page_search_root()
by openldap-its＠openldap.org 22 Jul '24

22 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10241 Issue ID: 10241 Summary: Crash in mdb_page_search_root() Product: LMDB Version: 0.9.24 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: david.komarek(a)whalebone.io Target Milestone: --- Hello, The LMDB is crashing in mdb_page_search_root() on following instruction `0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to following line in source code - https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485 (while access mp_flags in MDB_page structure) Here is callstack as generated by core dump (without symbols as we're using package from Ubuntu repositories) ``` Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. #3 0x00007f8522148a70 in mdb_get () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 No symbol table info available. ``` Translation ``` #0 mdb_page_search_root() #1 mdb_page_search() #2 mdb_cursor_set() #3 mdb_get() ``` Registers in time of crash: ``` rax 0x2 2 rbx 0x7ffcd8d2a100 140723946168576 rcx 0x3 3 rdx 0x7f825baf7000 140197860700160 rsi 0x1000 4096 rdi 0x7f851c00f4d0 140209677202640 rbp 0x0 0x0 rsp 0x7ffcd8d29e40 0x7ffcd8d29e40 r8 0x7ffcd8d29e50 140723946167888 r9 0x7f851c00f5b8 140209677202872 r10 0x7f851c003090 140209677152400 r11 0x2ce33e6c02ce33e7 3234497591006606311 r12 0x0 0 r13 0x7ffcd8d2a510 140723946169616 r14 0x79 121 r15 0x7f851c003098 140209677152408 rip 0x7f85221479d2 0x7f85221479d2 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 k0 0x40 64 k1 0xfffff0f0 4294963440 k2 0xff01 65281 k3 0xffffffff 4294967295 k4 0xffffffff 4294967295 k5 0xffffffff 4294967295 k6 0xffffffff 4294967295 k7 0x0 0 ``` Our setup is following: We have single process (running in separate container) which reads and writes to LMDB. It opens environment with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open without flags. On the other hand we have several processes running in the single container, which are only allowed read (these processes crash). The environment is open with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs are open without flags. Transactions are open with MDB_RDONLY flag. Could you please investigate it? If you will need some other artifacts or comments, please let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10240] New: Information required about the end of support date for OpenLDAP ver 2.6.3
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10240 Issue ID: 10240 Summary: Information required about the end of support date for OpenLDAP ver 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, As we have integrated OpenLDAP 2.6.3 version in our application, we would like to know the community support availability end of date for this version, to plan our application maintenance accordingly. Could you please help us with this information. Thanks, Vivek S -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10236] New: fragmentation makes mdb_page_alloc slow
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10236 Issue ID: 10236 Summary: fragmentation makes mdb_page_alloc slow Product: LMDB Version: 0.9.31 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: aalekseyev(a)janestreet.com Target Milestone: --- Created attachment 1022 --> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit patch is relative to LMDB_0.9.31 It's a known problem that mdb_page_alloc can be slow when the free list is large and fragmented. [1] [2] [3] I'm not sure it's known *how* slow it can be. In our workload we saw a fragmented freelist leading to a pathological O(n^2) behavior. To handle a multi-page allocation we iterate loading chunks of the free list one by one, and at every iteration we do O(n) work to check if the allocation can succeed. Even small-ish allocations (tens of pages) are repeatedly hitting this edge case, with free list growing to ~1000000, and the outer loop taking ~2000 iterations (10^9 worth of work in total, just to allocate a few pages). Even though I'm sure there are ways to avoid hitting this pathological scenario so much (avoid values larger than 4k, or fix whatever causes fragmentation), it seems unacceptable to have a performance cliff this bad. I made a patch to make the allocation take ~O(n*log(n)), by loading and merging multiple chunks at once instead of doing it one-by-one. I'd appreciate it if someone could review the patch (attached), improve it, and/or come up with an alternative fix. The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but it performs well enough to speed up our pathological workload by ~20x (which is still ~3x away from the non-fragmented case). Anyway, the main thing that warrants scrutiny is the change in `mdb.c`: I understand very little about lmdb internals and I worry that loading multiple pages at once instead of one-by-one might break something. [1] issue #8664 [2] https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa… [3] https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10239] New: The slapd domain name is inconsistent, synchronization cannot be modified by the rewrite dn parameter dc.
by openldap-its＠openldap.org 16 Jul '24

16 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10239 Issue ID: 10239 Summary: The slapd domain name is inconsistent, synchronization cannot be modified by the rewrite dn parameter dc. Product: OpenLDAP Version: 2.4.44 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 2458943823(a)qq.com Target Milestone: --- /etc/openldap/slapd: syncrepl rid=002 provider=ldap://172.18.1.1 bindmethod=simple binddn="cn=Manager,dc=wsc,dc=ls,dc=com" credentials=lnewnews1tter searchbase="dc=wsc,dc=ls,dc=com" schemachecking=off type=refreshAndPersist retry="60 +" rewrite dn "dc=wsc,dc=ls,dc=com" "dc=wsc,dc=slave1,dc=ls,dc=com" The error is as follows: 66912211 /etc/openldap/slapd.conf: line 281: Error: parse_syncrepl_line: unable to parse "rewrite" . 66912211 failed to add syncinfo slaptest: bad configuration directory! -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10238] New: libldap-2.5-0 kept back from upgrade
by openldap-its＠openldap.org 12 Jul '24

12 Jul '24

https://bugs.openldap.org/show_bug.cgi?id=10238 Issue ID: 10238 Summary: libldap-2.5-0 kept back from upgrade Product: JLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JLDAP Assignee: bugs(a)openldap.org Reporter: sonny_ward23(a)yahoo.com Target Milestone: --- sonny@sjw-T470p:~$ sudo apt update Ign:1 https://mirrors.ocf.berkeley.edu/linuxmint-packages virginia InRelease Hit:2 https://dl.google.com/linux/chrome/deb stable InRelease Hit:3 https://mirrors.ocf.berkeley.edu/linuxmint-packages virginia Release Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease Hit:5 http://mirror.arizona.edu/ubuntu jammy InRelease Hit:6 http://mirror.arizona.edu/ubuntu jammy-updates InRelease Hit:7 http://mirror.arizona.edu/ubuntu jammy-backports InRelease Reading package lists... Done Building dependency tree... Done Reading state information... Done 1 package can be upgraded. Run 'apt list --upgradable' to see it. sonny@sjw-T470p:~$ apt list --upgradable -a Listing... Done libldap-2.5-0/jammy-updates 2.5.18+dfsg-0ubuntu0.22.04.1 amd64 [upgradable from: 2.5.17+dfsg-0ubuntu0.22.04.1] libldap-2.5-0/now 2.5.17+dfsg-0ubuntu0.22.04.1 amd64 [installed,upgradable to: 2.5.18+dfsg-0ubuntu0.22.04.1] libldap-2.5-0/jammy-security 2.5.16+dfsg-0ubuntu0.22.04.2 amd64 libldap-2.5-0/jammy 2.5.11+dfsg-1~exp1ubuntu3 amd64 sonny@sjw-T470p:~$ sudo apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages have been kept back: libldap-2.5-0 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. sonny@sjw-T470p:~$ apt show libldap-2.5-0 -a Package: libldap-2.5-0 Version: 2.5.18+dfsg-0ubuntu0.22.04.1 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Phased-Update-Percentage: 20 Download-Size: 183 kB APT-Sources: http://mirror.arizona.edu/ubuntu jammy-updates/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.17+dfsg-0ubuntu0.22.04.1 Status: install ok installed Priority: optional Section: libs Source: openldap Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Download-Size: unknown APT-Manual-Installed: yes APT-Sources: /var/lib/dpkg/status Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.16+dfsg-0ubuntu0.22.04.2 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 579 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Download-Size: 183 kB APT-Sources: http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. Package: libldap-2.5-0 Version: 2.5.11+dfsg-1~exp1ubuntu3 Priority: optional Section: libs Source: openldap Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 573 kB Depends: libc6 (>= 2.34), libgnutls30 (>= 3.7.2), libsasl2-2 (>= 2.1.27+dfsg2) Recommends: libldap-common Conflicts: ldap-utils (<= 2.1.23-1) Replaces: libldap-2.3-0, libldap2 Homepage: https://www.openldap.org/ Task: server-minimal, print-server, ubuntu-desktop-minimal, lamp-server, samba-server, ubuntu-desktop, cloud-image, postgresql-server, ubuntu-desktop-raspi, ubuntu-wsl, mail-server, server, ubuntu-server-raspi, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi Download-Size: 184 kB APT-Sources: http://mirror.arizona.edu/ubuntu jammy/main amd64 Packages Description: OpenLDAP libraries These are the run-time libraries for the OpenLDAP (Lightweight Directory Access Protocol) servers and clients. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10222] New: mdb_dump page has outdated information about user-defined comparison functions
by openldap-its＠openldap.org 28 Jun '24

28 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10222 Issue ID: 10222 Summary: mdb_dump page has outdated information about user-defined comparison functions Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: tools Assignee: bugs(a)openldap.org Reporter: zach.vonler(a)sambanovasystems.com Target Milestone: --- Created attachment 1019 --> https://bugs.openldap.org/attachment.cgi?id=1019&action=edit Patch to mdb_dump man page The `mdb_dump` man page contains an outdated section warning that databases created with user-defined comparison functions cannot be dumped and reloaded without changes to the `mdb_load` program. The `-a` option that was added to the `mdb_load` program in this commit https://github.com/openldap/openldap/commit/7796aaebcd1b937233adab5b1f3d3a1… made it possible to reload such databases, so this patch updates the `mdb_dump` man page to reflect that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10147] New: Bind dn is getting malformed inside ldap_sasl_bind function
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10147 Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: satishkumar1728(a)gmail.com Target Milestone: --- Hi team, We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr" Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10175] New: Secure LDAP is not working on GCC 10.3.0
by openldap-its＠openldap.org 25 Jun '24

25 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10175 Issue ID: 10175 Summary: Secure LDAP is not working on GCC 10.3.0 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: bluesoulprince(a)gmail.com Target Milestone: --- Hi Team, We have recently migrated our C++ application which is using OpenLDAP 2.6 to GCC version 10.3.0. We are observing difference in LDAP behavior. The non-secure version of LDAP is able to return the result in GCC 10.3.0, however when we switch to secure LDAP, it is not able to return with result. There was no compilation / build issue observed while building our application. Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility issues over GCC 10.3.0? If there are any issues identified over this version, how to resolve those? in which version fixes for them are available? Thanks, Vivek -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10228] New: config LDAP_BACK_CONN_PRIV_MAX to higher value
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10228 Issue ID: 10228 Summary: config LDAP_BACK_CONN_PRIV_MAX to higher value Product: OpenLDAP Version: 2.5.16 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shaosong.li(a)salesforce.com Target Milestone: --- Hi, LDAP_BACK_CONN_PRIV_MAX parameter is set to 256 by below config, https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv… Can we set this value to a higher value, such as 7k/10k, which is commonly used in PingDirectory. Any reason that we set this value to a low value like 256, thanks. -- You are receiving this mail because: You are on the CC list for the issue.

2 8

[Issue 10060] New: libldap: ldap_result return value differs depending on if a search response is already in the response list or not
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10060 Issue ID: 10060 Summary: libldap: ldap_result return value differs depending on if a search response is already in the response list or not Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: david(a)hardeman.nu Target Milestone: --- ldap_result(3) is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… On this line, ldap_result will call wait4msg: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… wait4msg is defined here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If a response for a given msgid is already stored in the response list, and all=1, the whole message chain will be returned by the call from wait4msg to chkResponseList here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And rc will be set on the next line to the head of the message chain. If a response for a given msgid is *not* already stored in the response list, wait4msg will eventually call try_read1msg here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… If try_read1msg manages to receive the final search result message for a given msgid, it will be noted here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… The whole chain will be returned here: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… And the return code will be the tag of the *last* message in the chain, as opposed to the *first* message in the chain: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… Which will result in different return codes for chains of multiple messages (i.e. search results with all=1). -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 10138] New: Allow generating multiple nested read transactions from a write transaction
by openldap-its＠openldap.org 18 Jun '24

18 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10138 Issue ID: 10138 Summary: Allow generating multiple nested read transactions from a write transaction Product: LMDB Version: 0.9.30 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hello, I have a feature request. Would it be possible to read a database from the point of view of a non-yet-committed write transaction? What I want to do is to write a lot of entries into a database, use a couple of threads to read those entries (using MDB_NOTLS) to generate a lot of new entries (that will be written to disk and then once the generation is done, drop the read-transaction handles and write (with MDB_APPEND) those new entries from disk into LMDB. This would have been possible if I had committed the first entries, but unfortunately, it is impossible. I need to do this in the same transaction. Have a great day, kero -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 10225] New: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function
by openldap-its＠openldap.org 07 Jun '24

07 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10225 Issue ID: 10225 Summary: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: yaneurabeya(a)gmail.com Target Milestone: --- tlso_session_pinning(..) does not initialize the `digest` stack memory before referring to it later on in the function. This can result in a library crash if (for whatever reason) keyhash.bv_val fails to initialize properly on line 1191 [1]. This issue kind of goes hand in hand with bug 10224. 1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10220] New: Feature Request: new option for append-only write transaction
by openldap-its＠openldap.org 31 May '24

31 May '24

https://bugs.openldap.org/show_bug.cgi?id=10220 Issue ID: 10220 Summary: Feature Request: new option for append-only write transaction Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xhtang518(a)gmail.com Target Milestone: --- My project uses LMDB to store values larger than 100KB, and rarely delete values. So I can afford wasting some space on free pages, then LMDB can reduce 4KB-write operations and improve write performance when committing write transactions. I suppose this feature is not hard to implement: just pretend the free-list is empty in this transaction if the new option is present. Is this feature reasonable? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10182] New: slapo-alias doesn't work with static operational attributes
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10182 Issue ID: 10182 Summary: slapo-alias doesn't work with static operational attributes Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- It only checks in rs->sr_operational_attrs which is for dynamically generated opattrs, and ignores them if they're in the entry itself. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10104] New: Add alias overlay to contrib
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10104 Issue ID: 10104 Summary: Add alias overlay to contrib Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10188] New: autogroup doesn't allow a group to be a member of another group
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10188 Issue ID: 10188 Summary: autogroup doesn't allow a group to be a member of another group Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Try setting up autogroup (autogroup-attrset groupOfURLs memberURL member) and loading the following ldif. You'll notice that neither group is marked as a member: dn: cn=test objectClass: device dn: cn=group,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(description=a member) memberURL: ldap:///cn=test??sub?(description=I'm in) description: a member dn: cn=member,cn=test objectClass: device description: I'm in dn: cn=another,cn=test objectClass: mygroupOfURLs memberURL: ldap:///cn=test??sub?(objectclass=groupOfURLs) description: I'm in Just set up mygroupOfURLs with at least a MAY that includes "cn $ description $ member $ memberURL" somehow, e.g. objectClass ( NetscapeLDAPobjectClass:33.1 NAME 'mygroupOfURLs' SUP groupofurls STRUCTURAL MAY member ) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs