Uploading authority certificate with expiry date beyond 2038

Uploading authority certificate with expiry date beyond 2038

[Devender Rao]

[-- Attachment #1: Type: text/html, Size: 11953 bytes --]

Re: Uploading authority certificate with expiry date beyond 2038

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Uploading authority certificate with expiry date beyond 2038

[Lei YU]

On Thu, Mar 12, 2020 at 2:56 AM Patrick Williams <patrick@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/