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.
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.
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.
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.
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.
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.
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.
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.
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.
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.