Possible 2038 bug in credentials cache api

[William Brown]

> 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