Uploading authority certificate with expiry date beyond 2038

[Lei YU]

On Thu, Mar 12, 2020 at 2:56 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Wed, Mar 11, 2020 at 09:49:02AM +0000, Devender Rao wrote:
> > As time_t data structure is defined as int32 it can hold up to a maximum value
> There is significant upstream work going on to transition time_t to a 64
> bit integer even on 32 bit machines (x86-64 and ARM64 already have a 64
> bit time_t).
>
> Kernel changes are already in as of 5.1 to support a userspace with
> 64-bit time_t but the kernel itself uses 32-bit internally.  There is a
> merge that is heading into 5.6 to change the kernel (but I don't think
> we need this):
>
> https://lore.kernel.org/lkml/CAK8P3a2iZyA1VSFqvcEc9o59F76GgzLBiOAmEuHKD81FErPLDQ@mail.gmail.com/
>
> That pull request mentions userspace changes coming in glibc-2.32 that
> will use the 64-bit time_t syscalls and transition userspace over to
> 64-bit everywhere.  glibc-2.32 is scheduled for August 2020.
>
> > Probable solutions
> > 1) Do nothing as the chances of uploading a certificate with expiry date > 18
> > chances never happen
> > 2) Return error to the caller if the expirty date is greater than 2038.
>
> With this in mind I'd go with #2 in the short term until we get the
> upstream changes.

Agreed, a fair certificate should not have such an expiry date.

>
> These coming changes should cause us to think through any cases where we
> might be relying on a 32-bit time_t, especially in serialization.  I
> have a little concern that we're going to end up breaking some upgrade
> paths when we are using binary formats (like some code using Cereal
> might be).  How do we want to audit and fix that now?
>

There is an interesting article in LWN talking about how Debian will
handle the 2038 case:
https://lwn.net/Articles/812767/