#829366 doesn't allow for creation of keys with 90-year expiry

Package:
gnupg2
Source:
gnupg2
Submitter:
Luke Faraone
Date:
2025-04-27 11:36:02 UTC
Severity:
normal
#829366#5
Date:
2016-07-02 19:43:54 UTC
From:
To:
Creating a key that expires in 89 years correctly sets an expiry of 2105, but
attempting to set an expiry of 90 years or greater results in an expirty date
that wraps around to 1970.

Curiously, the time on such wrapped-around expiries is always 13:09:41.
#829366#10
Date:
2016-07-02 20:05:17 UTC
From:
To:
Luke Faraone wrote:
32-bit integer number of seconds since the Unix epoch only allows
representing ~136 years since 1970. If you use a *signed* 32-bit integer
you get the more famous Y2038 problem.

There are other instances of the Y2106 bug in the archive, e.g. BIND's
struct isc_time also represents seconds since the epoch with an unsigned
int.
#829366#15
Date:
2016-07-03 13:35:18 UTC
From:
To:
Right, the underlying OpenPGP specification doesn't permit this because
of its use of 32-bits unsigned seconds-since-the-unix epoch:

https://tools.ietf.org/html/rfc4880#section-3.5

Setting aside the advisiability of a 90-year expiration date (it is
*not* advisable), i'm wondering how you'd like to proceed with this bug
report.  If GnuPG gave an error when asked to set timestamps outside of
its representable range, would that be sufficient to close this bug?

Otherwise, this can only be resolved with an update to the OpenPGP
specification, and GnuPG adopting that future spec.
#829366#20
Date:
2016-07-04 08:04:45 UTC
From:
To:
On Sun,  3 Jul 2016 15:35, dkg@fifthhorseman.net said:
and wraps in 2038.  Thus we have a hard time to work with such time
stamps on 32 bit glibc boxes.  For 64 bit machines we could extend the
existing check

#if SIZEOF_TIME_T <= 4 && !defined (HAVE_UNSIGNED_TIME_T)
	    if ( (time_t)((ulong)(curtime+interval)) < 0 )
	      tty_printf (_("Your system can't display dates beyond 2038.\n"
                            "However, it will be correctly handled up to"
                            " 2106.\n"));
            else
#endif /*SIZEOF_TIME_T*/

to reject dates beyond 2106, with a message like:

 "The OpenPGP protocol does not support dates beyond 2106-02-06."


BTW: More than 10 years ago I tried to convince the glibc maintainer to
start switching to a 64 bit time_t on 32 bit systems.  He rejected that
with the idea that time_t was never designed for calendar time but only
for system (up-)time.  So for gpgsm (X.509) I resorted to use a 16 byte
string for all timestamps ("20160731T140000") which requires quite some
extra code but was needed because real world certificates had expiration
dates beyond 2038 (X.509 expresses them in several kinds of strings).

This would open a can of worms...  I have seen you mail to the WG, though.


Salam-Shalom,

   Werner