openldap-bugs

openldap-bugs@openldap.org

1 participants
20896 discussions

[Issue 9527] New: typo in nssov/README at line 68 "olDatabase" should be "olcDatabase"
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9527 Issue ID: 9527 Summary: typo in nssov/README at line 68 "olDatabase" should be "olcDatabase" Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- At line 68 in nssov/README, the word olDatabase should be olcDatabase If I could generate a merge request, I would point you to https://git.openldap.org/rdubner/openldap origin/nssov-README-patch But that seems overkill for adding a single character -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9525] New: Fix contrib modules to properly honor build flags
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9525 Issue ID: 9525 Summary: Fix contrib modules to properly honor build flags Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the contrib makefiles use a variable "OPT", instead they should be fixed to correctly honor CFLAGS, CPPFLAGS, and LDFLAGS as appropriate -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9520] New: slapd should fail if linked with libsodium and rgon2.so is load with parameter with p>=1
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9520 Issue ID: 9520 Summary: slapd should fail if linked with libsodium and rgon2.so is load with parameter with p>=1 Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- IMHO slapd should simply fail to start in case 1. it is linked against libsodium 2. and argon2.so is load with parameter with p>=1 Because this is a config error it should log a clear error message at config log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9519] New: Adopt the namedObject draft
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9519 Issue ID: 9519 Summary: Adopt the namedObject draft Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Lives here https://tools.ietf.org/html/draft-stroeder-namedobject -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9518] New: Configuration parameter to force TLSv1.2 (-no_tls1_3)
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9518 Issue ID: 9518 Summary: Configuration parameter to force TLSv1.2 (-no_tls1_3) Product: OpenLDAP Version: 2.4.50 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: tom.bosmans(a)be.ibm.com Target Milestone: --- Hi, I'm running into a problem during creation of an Ansible playbook that uses the community.general.ldap_entry module, which in turn depends on python-ldap , that uses the openldap libraries. My (openldap) server is configured for TLS 1.2, but does not support TLS 1.3. openssl version: OpenSSL 1.1.1k (have tried 1.1.1g as well). So the root cause is that openssl, if it's compiled with TLS v1.3 , will try TLS v1.3. If that doesn't work because the server does not support it, it just stops. This is madness. openssl s_client -connect isva.test:636 -showcerts -state CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL3 alert read:fatal:handshake failure SSL_connect:error in error Now within openssl , there's a parameter that you can set to skip tls 1.3. Great. So this works. openssl s_client -connect isva.test:636 -showcerts -state -no_tls1_3 CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=0 CN = isva.test verify error:num=18:self signed certificate verify return:1 depth=0 CN = isva.test ... But with ldapsearch, there's no option to pass this . I've tried changing the cipher suite in .ldaprc, but to no avail. The TLSv1.3 ciphers are always used. [tbosmans@tbosmans-p73 ~]$ ldapsearch -x -H ldaps://isva.test -D "cn=bind,o=whatever" -w "pasword" -b "o=test" -v -d1 ldap_url_parse_ext(ldaps://isva.test) ldap_initialize( ldaps://isva.test:636/??base ) ldap_create ldap_url_parse_ext(ldaps://isva.test:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP isva.test:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.42.135:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in error TLS: can't connect: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [tbosmans@tbosmans-p73 ~]$ cat .ldaprc TLS_REQCERT never TLS_ECNAME ECDHE TLS_CIPHER_SUITE ECDHE-ECDSA-ARIA256-GCM-SHA384 So it would be great it there was an option equivalent to "-no_tls1_3" for the openldap client tools (or there may be a way to achieve this that I've missed so far). -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9517] New: Documenting how to pass Argon2 configuration parameters when loading the module
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9517 Issue ID: 9517 Summary: Documenting how to pass Argon2 configuration parameters when loading the module Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gilbert.kowarzyk(a)servicenow.com Target Milestone: --- It is possible to pass the configuration parameters for the argon2 module when loading the module in OpenLDAP, and they are properly employed when using ldappasswd. Nevertheless, it took me a considerable amount of time to find how to provide the config when loading the module. The way I was able to provide the argon2 configuration values was by adding the following to the slaps.ldif file: olcModuleload: argon2.so m=XXXX t=YYYY p=ZZZZZ (where XXXX, YYYY, and ZZZZ are the configuration values). The syntax was initially not clear to me, and required a lot of trial an error (I was not able to find documentation that clearly explained this syntax). Thanks in advance! -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9515] New: datamorph overlay fails to build
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9515 Issue ID: 9515 Summary: datamorph overlay fails to build Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- datamorph.c:1706:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c:1706:30: note: each undeclared identifier is reported only once for each function it appears in datamorph.c: In function 'datamorph_add_mapping': datamorph.c:1771:33: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_mapping_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_info_cleanup': datamorph.c:1795:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_mapping_cleanup': datamorph.c:1853:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_config_build_attr': datamorph.c:1965:10: warning: implicit declaration of function 'avl_apply'; did you mean 'acl_append'? [-Wimplicit-function-declaration] return avl_apply( info->ti_enum.to_db, datamorph_config_build_enum, ^~~~~~~~~ acl_append datamorph.c: In function 'datamorph_cfadd': datamorph.c:1988:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9511] New: make depend shouldn't error on slapi/plugin.c if no ltdl.h found
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9511 Issue ID: 9511 Summary: make depend shouldn't error on slapi/plugin.c if no ltdl.h found Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- make depend throws the following error if ltdl.h is not found: make[3]: Entering directory '/home/quanah/qtest/openldap/qbuild/servers/slapd/slapi' ../../../../build/mkdep -l -d "../../../../servers/slapd/slapi" -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../../include -I../../../../servers/slapd/slapi/.. -I../../../../servers/slapd/slapi plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c ../../../../servers/slapd/slapi/plugin.c:33:10: fatal error: ltdl.h: No such file or directory #include <ltdl.h> ^~~~~~~~ I.e., it should probably just exit if HAVE_LTDL_H is not true or similar. At the least: diff --git a/servers/slapd/slapi/plugin.c b/servers/slapd/slapi/plugin.c index 7ebc23f3a..f816ea34e 100644 --- a/servers/slapd/slapi/plugin.c +++ b/servers/slapd/slapi/plugin.c @@ -30,7 +30,9 @@ /* * Note: if ltdl.h is not available, slapi should not be compiled */ +#ifdef HAVE_LTDL_H #include <ltdl.h> +#endif gets rid of the error during make depend -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9396] New: Docs might recommend applicationProcess for ppolicy entries
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9396 Issue ID: 9396 Summary: Docs might recommend applicationProcess for ppolicy entries Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 779 --> https://bugs.openldap.org/attachment.cgi?id=779&action=edit Suggested doc patch Hello, The ppolicy section of the Admin Guide does not say why the "people" object class is present in the example policy entry. I suggest that the docs explain. Otherwise the reader is left wondering why the particular choice of structural object class was made. The less informed reader is left wondering why a second object class is required at all. I also suggest that instead of the "people" object class, that the applicationProcess object class be used in the example to provide the structural object class the entry requires. The slapo-ppolicy man page might also provide guidance. Attached is a suggested patch, provided so that you have something to work from. If you're not happy with the patch go ahead and discard it, I'm not advocating any particular wording. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9337 Issue ID: 9337 Summary: Slapd crash with lastbind overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Hello, I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1 master and 1 replica), and when i activate the lastbind overlay. The replica server crash like this : slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in slapd[400000+1d8000] The database is this one with overlay loaded : dn: cn=module{0},cn=config olcModuleLoad: {0}sssvlv.la olcModuleLoad: {1}ppolicy.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}lastbind.la olcModuleLoad: {4}pw-sha2.la dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcUpdateRef: ldap://master.server:389/ If i add this configuration it crash : dn: olcOverlay={2}lastbind objectClass: olcOverlayConfig objectClass: olcLastBindConfig olcOverlay: {2}lastbind olcLastBindPrecision: 60 olcLastBindForwardUpdates: TRUE Does the release 2.5.51 or 2.5.52 could solve this issue ? Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 11

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs