| Subject: | Year 2038 fixes |
In January 2038, the Unix time value overflows signed 32-bit integers,
which will break a wide variety of krb5 operations. This problem can
already be observed by trying to set a very long expiration time for a
principal (modprinc -pwexpire "25 years" princname).
On platforms with 32-bit time_t, this problem is essentially
intractable; we would have to avoid all platform functions using time_t
and find some other way of obtaining the current time. Also, even if
krb5 continued working after 2038 on such systems, the remainder of the
operating system would not. So our solution can be predicated on 64-
bit time_t.
On platforms with 64-bit time_t, we continue to have many issues
because krb5_timestamp is fixed at 32 bits. This type appears in
numerous libkrb5 APIs and public structures, in protocols such as
kadmin and iprop, and in file formats such as the db2 KDB module.
Migrating to a 64-bit krb5_timestamp would require a huge transition.
A less difficult option is to use the sign bit of krb5_timestamp to
represent time values up to year 2106. The value -1 can remain as a
distinguished value. To do this we will need to:
* Create libkrb5 API functions to convert krb5_timestamp to time_t and
vice versa.
* Scour the code base for uses of krb5_timestamp values, and use the
conversion functions wherever they are needed.
* Make sure that negative values of krb5_timestamp can be encoded and
decoded wherever they appear in protocol and file formats.
We also need to consider places in the code which subtract one
krb5_timestamp value from another (such as when checking clock skew),
if one of the values can legitimately be negative.
which will break a wide variety of krb5 operations. This problem can
already be observed by trying to set a very long expiration time for a
principal (modprinc -pwexpire "25 years" princname).
On platforms with 32-bit time_t, this problem is essentially
intractable; we would have to avoid all platform functions using time_t
and find some other way of obtaining the current time. Also, even if
krb5 continued working after 2038 on such systems, the remainder of the
operating system would not. So our solution can be predicated on 64-
bit time_t.
On platforms with 64-bit time_t, we continue to have many issues
because krb5_timestamp is fixed at 32 bits. This type appears in
numerous libkrb5 APIs and public structures, in protocols such as
kadmin and iprop, and in file formats such as the db2 KDB module.
Migrating to a 64-bit krb5_timestamp would require a huge transition.
A less difficult option is to use the sign bit of krb5_timestamp to
represent time values up to year 2106. The value -1 can remain as a
distinguished value. To do this we will need to:
* Create libkrb5 API functions to convert krb5_timestamp to time_t and
vice versa.
* Scour the code base for uses of krb5_timestamp values, and use the
conversion functions wherever they are needed.
* Make sure that negative values of krb5_timestamp can be encoded and
decoded wherever they appear in protocol and file formats.
We also need to consider places in the code which subtract one
krb5_timestamp value from another (such as when checking clock skew),
if one of the values can legitimately be negative.