https://bugs.openldap.org/show_bug.cgi?id=8491
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8491
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Target Milestone|2.7.0 |---
Resolution|--- |FIXED
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
already covered by slapmodify test007
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8890
--- Comment #18 from tg(a)debian.org <tg(a)debian.org> ---
On Sat, 21 Sep 2024, tg(a)debian.org wrote:
>AIUI, this should likely be something like:
… make that…
+- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) );
+ keys[0].bv_len = snprintf(keys[0].bv_val,
+- LDAP_PVT_INTTYPE_CHARS(long),
++ LDAP_PVT_INTTYPE_CHARS(long long),
+- "%ld", slap_get_time());
++ "%lld", (long long)slap_get_time());
… of course. (It’s 03:04 in the night, and re-reading those
comments from above was not effortless.)
bye,
//mirabilos
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8890
--- Comment #17 from tg(a)debian.org <tg(a)debian.org> ---
On Sat, 21 Sep 2024, openldap-its(a)openldap.org wrote:
>https://bugs.openldap.org/show_bug.cgi?id=8890
>I didn't understand Howard's comment ('the unconditional use of "long long"
[…]
Looking at it *again*, with some years of distance, I *think*
I now see what Howard’s barely comprehensible and rather rude
comments were meant to point out.
I did not see it at that time because ⓐ I was trying, and, as
a nōn-English-native speaker, failing to puzzle out what he was
saying, and ⓑ the OpenLDAP code’s use of abstractions here has
massively reduced its legibility.
+ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+ keys[0].bv_len = snprintf(keys[0].bv_val,
+ LDAP_PVT_INTTYPE_CHARS(long),
+- "%ld", slap_get_time());
++ "%lld", (long long)slap_get_time());
I think the first line of that is the point of critique. On
repeat reading, it looks like it tries to figure out how many
bytes are needed to represent a long, then allocates a buffer
sized by this.
As I correctly pointed out, this is a separate issue. However,
Howard rejected both the immediate fix of printing wrong data
RIGHT NOW (and likely truncating that at some point in the future)
and this follow-up bug to address that truncation.
AIUI, this should likely be something like:
+- keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
++ keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long long) );
+ keys[0].bv_len = snprintf(keys[0].bv_val,
+ LDAP_PVT_INTTYPE_CHARS(long),
+- "%ld", slap_get_time());
++ "%lld", (long long)slap_get_time());
Of course, someone who actually knows wth LDAP_PVT_INTTYPE_CHARS
is needs to ensure that it DTRT for an argument of “long long”
first.
bye,
//mirabilos
--
You are receiving this mail because:
You are on the CC list for the issue.
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.