Possible 2038 bug in credentials cache api

[Greg Hudson]

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