openldap-bugs January 2024

openldap-bugs@openldap.org

1 participants
92 discussions

[Issue 9827] New: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id
by openldap-its＠openldap.org 28 Jun '24

28 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=9827 Issue ID: 9827 Summary: Feature request for module argon2.so to support Argon2i, Argon2d, Argon2id Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: juergen.sprenger(a)swisscom.com Target Milestone: --- Hi, This is a feature request. I would like to be able to chooses between Argon2i, Argon2d and Argon2id in slappasswd like in argon2 command: # argon2 Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) | -k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)] Password is read from stdin Parameters: salt The salt to use, at least 8 characters -i Use Argon2i (this is the default) -d Use Argon2d instead of Argon2i -id Use Argon2id instead of Argon2i -t N Sets the number of iterations to N (default = 3) -m N Sets the memory usage of 2^N KiB (default 12) -k N Sets the memory usage of N KiB (default 4096) -p N Sets parallelism to N threads (default 1) -l N Sets hash output length to N bytes (default 32) -e Output only encoded hash -r Output only the raw bytes of the hash -v (10|13) Argon2 version (defaults to the most recent version, currently 13) -h Print argon2 usage Example: /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so i" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so d" -s secret /usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o module-load="argon2.so id" -s secret Best regards Juergen Sprenger -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[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 10140] New: Add microsecond timestamp format for local file logging
by openldap-its＠openldap.org 20 Jun '24

20 Jun '24

https://bugs.openldap.org/show_bug.cgi?id=10140 Issue ID: 10140 Summary: Add microsecond timestamp format for local file logging Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Add microsecond-level timestamps to local file logging. Format is: "YYYY-mm-ddTHH:MM:SS.ffffffZ" The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or interest in this work to any party. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Gregory Noe Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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 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 10167] New: slapo-memberof should have a way of reacting to a member entry being added after group referencing it
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10167 Issue ID: 10167 Summary: slapo-memberof should have a way of reacting to a member entry being added after group referencing it Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a group (with member: values) is added before the member entries exist, the memberof values never get populated. This can happen e.g. during replication. No idea how it meshes with the refint functionality of memberof if it's indeed reconcilable at all. Silly example (Hird's memberof will be empty): ```ldif dn: cn=GNU,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hurd,ou=Groups,dc=example,dc=com dn: cn=Hurd,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Hird,ou=Groups,dc=example,dc=com member: cn=Roger Rabbit,ou=People,dc=example,dc=com dn: cn=Hird,ou=Groups,dc=example,dc=com objectClass: groupOfNames member: cn=Tweety Bird,ou=People,dc=example,dc=com member: cn=Hurd,ou=Groups,dc=example,dc=com ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10161] New: Move nested group support to its own overlay
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10161 Issue ID: 10161 Summary: Move nested group support to its own overlay Product: OpenLDAP Version: 2.6.6 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: --- Adding the feature to dynlist has made that code overly complex, along with killing performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10103] New: Contrib OIDs inconsistent
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10103 Issue ID: 10103 Summary: Contrib OIDs inconsistent 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: --- When the latest batch of contrib overlays were added, the OIDs list wasn't updated and OIDs inside the code populated properly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10165] New: back-meta fails to bind to target when proxying an internal operation
by openldap-its＠openldap.org 21 May '24

21 May '24

https://bugs.openldap.org/show_bug.cgi?id=10165 Issue ID: 10165 Summary: back-meta fails to bind to target when proxying an internal operation Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- When the target is configured as follows: idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override and an overlay issues an internal operation, back-meta attempts to open a new connection to the target, but the bind fails, so the internal operation cannot be executed. The target server returns the following error (as logged by back-meta): <unauthenticated bind (DN with no password) disallowed> Example configuration of the target server: authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth cn=config logfile ./main.log database config database mdb directory ./main rootdn cn=config suffix o=example.com overlay accesslog logdb cn=log logops writes logsuccess true database mdb suffix cn=log directory ./log -- You are receiving this mail because: You are on the CC list for the issue.

1 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2024