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.
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.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=10044
Issue ID: 10044
Summary: dynlist sometimes crashes when a search operation is
abandoned
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: ---
Playing with the DB provided in ITS#10041 on master, interrupting the
ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the
debugger shows dynlist_search2resp touching memory freed by
dynlist_search_cleanup already, which doesn't make sense. Might be something
else is happening at the same time.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9952
Issue ID: 9952
Summary: Crash on exit with OpenSSL 3
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: artur.zaprzala(a)gmail.com
Target Milestone: ---
A program using libldap will crash on exit after using SSL connection.
How to reproduce on CentOS 9:
Uncomment the following lines in /etc/pki/tls/openssl.cnf:
[provider_sect]
legacy = legacy_sect
[legacy_sect]
activate = 1
Run the command (you must enter a valid LDAP server address):
python3 -c "import ldap; ldap.initialize('ldaps://<LDAP SERVER
ADDRESS>').whoami_s()"
Another example (no server required):
python3 -c "import ctypes;
ctypes.CDLL('libldap.so.2').ldap_pvt_tls_init_def_ctx(0)"
Results:
Segmentation fault (core dumped)
Backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0 ___pthread_rwlock_rdlock (rwlock=0x0) at pthread_rwlock_rdlock.c:27
1 0x00007ffff7c92f3d in CRYPTO_THREAD_read_lock (lock=<optimized out>) at
crypto/threads_pthread.c:85
2 0x00007ffff7c8b126 in ossl_lib_ctx_get_data (ctx=0x7ffff7eff540
<default_context_int.lto_priv>, index=1, meth=0x7ffff7eb8a00
<provider_store_method.lto_priv>) at crypto/context.c:398
3 0x00007ffff7c98bea in get_provider_store (libctx=<optimized out>) at
crypto/provider_core.c:334
4 ossl_provider_deregister_child_cb (handle=0x5555555ed620) at
crypto/provider_core.c:1752
5 0x00007ffff7c8bf2f in ossl_provider_deinit_child (ctx=0x5555555d2650) at
crypto/provider_child.c:279
6 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:283
7 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:276
8 0x00007ffff7634af6 in legacy_teardown (provctx=0x5555555ee9f0) at
providers/legacyprov.c:168
9 0x00007ffff7c9901b in ossl_provider_teardown (prov=0x5555555ed620) at
crypto/provider_core.c:1477
10 ossl_provider_free (prov=0x5555555ed620) at crypto/provider_core.c:683
11 0x00007ffff7c63956 in ossl_provider_free (prov=<optimized out>) at
crypto/provider_core.c:668
12 evp_cipher_free_int (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1632
13 EVP_CIPHER_free (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1647
14 0x00007ffff7a6bc1d in ssl_evp_cipher_free (cipher=0x555555916c10) at
ssl/ssl_lib.c:5925
15 ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5915
16 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3455
17 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3392
18 0x00007fffe95edb89 in ldap_int_tls_destroy (lo=0x7fffe9616000
<ldap_int_global_options>) at
/usr/src/debug/openldap-2.6.2-1.el9_0.x86_64/openldap-2.6.2/libraries/libldap/tls2.c:104
19 0x00007ffff7fd100b in _dl_fini () at dl-fini.c:138
20 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:113
21 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143
22 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20
<main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2b8) at
../sysdeps/nptl/libc_start_call_main.h:74
23 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>,
argc=4, argv=0x7fffffffe2b8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe2a8) at ../csu/libc-start.c:409
24 0x000055555556b575 in _start ()
The problem is that ldap_int_tls_destroy() is called after the clean up of
libssl.
On program exit, at first default_context_int is cleaned up (OPENSSL_cleanup()
was registered with atexit()):
0 ossl_lib_ctx_default_deinit () at crypto/context.c:196
1 OPENSSL_cleanup () at crypto/init.c:424
2 OPENSSL_cleanup () at crypto/init.c:338
3 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:113
4 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143
5 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20
<main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2c8) at
../sysdeps/nptl/libc_start_call_main.h:74
6 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>,
argc=4, argv=0x7fffffffe2c8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe2b8) at ../csu/libc-start.c:409
7 0x000055555556b575 in _start ()
Then ossl_lib_ctx_get_data() tries to use default_context_int.lock, which is
NULL. ldap_int_tls_destroy() is called by ldap_int_destroy_global_options(),
registered by "__attribute__ ((destructor))".
It seems that shared library destructors are always called before functions
registered with atexit().
A solution may be to modify libraries/libldap/init.c to use atexit() instead of
"__attribute__ ((destructor))". atexit() manual page says: "Since glibc 2.2.3,
atexit() can be used within a shared library to establish functions that are
called when the shared library is unloaded.".
Functions registered with atexit() are called in the reverse order of their
registration, so libssl must by initialized before libldap. If the order is
wrong, libldap should detect it somehow and exit with abort().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9921
Issue ID: 9921
Summary: Tautology in clients/tools/common.c:print_vlv()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
contains:
tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
ldif ? "vlvResult" : "vlvResult", buf, rc );
The second parameter is always vlvResult, irrespective of the value of ldif.
--
You are receiving this mail because:
You are on the CC list for the issue.