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.

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?

-- 
Patrick Williams