From rbasch68 at gmail.com  Thu Oct  1 09:39:16 2026
From: rbasch68 at gmail.com (Richard Basch)
Date: Thu, 1 Oct 2026 09:39:16 -0400
Subject: Possible 2038 bug in credentials cache api
In-Reply-To: <C4311663-09D7-4ABD-B651-DD6AD3CDF48F@suse.de>
References: <E32E9C50-ABA5-4A48-9EB7-9B4717C4DF44@suse.de>
 <ea08a4f0-e7a1-4045-9e77-6ab248b0d585@mit.edu>
 <C4311663-09D7-4ABD-B651-DD6AD3CDF48F@suse.de>
Message-ID: <CA+ObhiURFydEaBOukVOVY3Rauw=2gfu0M4AJNMv7jguUkqtYnA@mail.gmail.com>

Wow... if an API can last >100 years from when it was developed? That would
be a first. But, by your logic, 64 bit isn't sufficient... that will
eventually be exhausted... probably not before civilization is long gone
though.

In this case, I side with Greg. There were some stupid things done in
Kerberos originally, e.g. 8 bit for kvno. However, even if nothing else is
done, by the time y2106 rolls around, inside the libraries, it can start
playing games like figuring out which range it applies to. To wait 140
years to create a collision, not really practical given lifespans -
entities likely won't still be valid for authentication, and crypto
standards will have shifted, so even the theoretical attack of waiting a
century for a collision is moot.

>From a purist standpoint, William is correct... From a practical attack and
working around fixed constraints, Greg's approach can STILL be extended to
the next cliff, without much effort.


On Wed, Sep 30, 2026 at 3:51?AM William Brown <wbrown at suse.de> wrote:

>
>
> > On 30 Sep 2026, at 16:57, Greg Hudson <ghudson at mit.edu> wrote:
> >
> > On 9/30/26 00:49, William Brown wrote:
> >> It appears that cc_time_t is a cc_uint32 which leads me to believe that
> users of this interface may fall into a yr 2038 bug by treating this as an
> int32t. What would be the best way to get this fixed in the various
> users/providers of this api?
> >
> > The project's strategy for y2038 is to continue to use 32-bit timestamps
> but treat them as unsigned.  See <
> https://k5wiki.kerberos.org/wiki/Projects/Timestamps_after_2038> .  A
> transition to 64-bit timestamps would be a large undertaking with
> disruptive consequences for downstream users of MIT krb5.
>
> The problem as I see it is that this causes the problem to be delayed till
> 2106 - sure maybe we'll all have retired by then, but then someone else has
> to deal with this. Wouldn't it be better to tackle this now then delay the
> issue, especially as there is just as much risk going from int32_t ->
> uint32_t as there is to int64_t? Just as much could break within this
> framework ....
>
> >
> > I don't believe there are a wealth of CCAPI users; I believe it is just
> the Kerberos source tree itself on Windows.  While the CCAPI is not a
> likely source of concern, there is a possibility that third-party consumers
> of libkrb5 may encounter y2038 bugs if they make use of krb5_timestamp
> values and don't take care to treat them as unsigned (which typically
> requires a cast, as krb5_timestamp is signed).
>
> MacOS uses it iirc, so I think they'll be affected too ....
>
> --
> Sincerely,
>
> William Brown
>
> Senior Software Engineer,
> Identity and Access Management
> SUSE Labs, Australia
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>