[20578] in Kerberos_V5_Development
Re: Possible 2038 bug in credentials cache api
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 30 02:57:19 2026
Message-ID: <ea08a4f0-e7a1-4045-9e77-6ab248b0d585@mit.edu>
Date: Wed, 30 Sep 2026 02:57:10 -0400
MIME-Version: 1.0
To: William Brown <wbrown@suse.de>, krbdev@mit.edu
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <E32E9C50-ABA5-4A48-9EB7-9B4717C4DF44@suse.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
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.
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).
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
