[pkg-gnupg-maint] Bug#829366: Bug#829366: Bug#829366: doesn't allow for creation of keys with 90-year expiry

[Werner Koch]

On Sun,  3 Jul 2016 15:35, dkg at fifthhorseman.net said:

> report.  If GnuPG gave an error when asked to set timestamps outside of
> its representable range, would that be sufficient to close this bug?

Which is actually problematic because on many system time_t is signed
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).

> Otherwise, this can only be resolved with an update to the OpenPGP
> specification, and GnuPG adopting that future spec.

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


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */