https://bugs.openldap.org/show_bug.cgi?id=10215
Issue ID: 10215
Summary: [QUESTION] FIPS Validated password hashing
Product: OpenLDAP
Version: 2.4.54
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 11tete11(a)gmail.com
Target Milestone: ---
Hi! we are in process of a certification, and we are using openldap of ubuntu
pro fips 20.04, that its the 2.4.54
At some point the auditor ask us, how the passwords are stored into ldap, and
we found this:
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
seems that that module do not use a FIPS validated library like "openssl" that
comes with ubuntu fips. and make it's own implementation of the sha512.
Is there any ldap module that uses the openssl library of the SO that in this
case its the openssl 1.1.1f to hash its passwords?, could be this
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
maybe if i'm understanding right?
thx!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10198
Issue ID: 10198
Summary: Crash in mdb_strerr on Windows
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: b.koch(a)beckhoff.com
Target Milestone: ---
The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code
112 (disk full).
Its "Arguments" parameter is an invalid pointer. The documentation says that
the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my
copy of Windows disagrees. Documentation for FormatMessageA:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form…
The error is (with addresses replaced by <...>):
Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in
ConsoleApplication1.exe: 0xC0000005: Access violation reading location
<buf+8*1024>.
Trivial fix: Change the last parameter to NULL (in this call:
https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…)
Bug 8361 is raising some additional issues in this code and it implies that the
va_list is somehow related to the padding hack (but I don't understand how that
is, to be honest), so I'm not sure whether the trivial fix would be fine.
Here is some code to reproduce the crash outside of liblmdb (tested with Visual
Studio 2022, x86 and x64, C++ console project):
#include <iostream>
#include <windows.h>
int main()
{
std::cout << "Hello World!\n";
char buf[1024];
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024);
char* msg = buf;
std::cout << msg;
}
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10084
Issue ID: 10084
Summary: Move away from DIGEST-MD5 as a default in the test
suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2
onwards. As such we should update our defaults in a couple of our test scripts
for master/2.7 at least. Are SCRAM mechanisms the go-to these days?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10210
Issue ID: 10210
Summary: ldapurl manpage references options that no longer
exist
Product: OpenLDAP
Version: 2.6.7
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: ---
-h ldaphost
Set the host.
-p ldapport
Set the TCP port.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10195
Issue ID: 10195
Summary: permissive modify control without value
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lesignor(a)cirad.fr
Target Milestone: ---
Hello,
A windows ldap client (dotnet) format the request with oid permissive modify
control like this :
00d0 30 84 00 00 00 1e 04 17 ........0.......
00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1
00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413.....
The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?).
With openldap 2.4.x this request was accepted.
With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid
protocol with error message : permissiveModify control value not absent
With ldapmodify from openldap, the same request is formatted without the last 2
bytes and is accepted.
Could it be possible to accept request with control without value formatted
with 04 00 to indicate no value ?
It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8613
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10167
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
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: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10071
Issue ID: 10071
Summary: Extra sids in cookie should only be ignored for replay
consideration
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: ---
A consumer's cookie might contain sids that the provider is not aware of. Those
are currently screened out. This is appropriate for initial checks whether/how
to allow the operation to go ahead but might be needed for content
determination in refresh/persist. As such the cookie should be retained rather
than edited in place.
I don't have the logs from a failed test at hand but will post the
analysis/logs if I find them again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10168
Issue ID: 10168
Summary: olcdbindex doesn't cleanup cleanly
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: ---
if you run the following modify against slapd (notice the olcDbMultival data is
wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the
olcDbIndex changes:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: member eq
olcDbIndex: memberof eq
-
add: olcDbMultival
olcDbMultival: member,memberOf 5,15
-
--
You are receiving this mail because:
You are on the CC list for the issue.