问题
The gpg --with-colon reports bad expiration date (although the key is usable for encryption) See "[expires: ????-??-??]"
gpg --with-colon key.ascii
pub:-:1024:17:77A54749D56561D6:2016-06-10:????-??-??::-:AAA AAA <AAA@somewhere.com>:
sub:-:2048:16:44479A86F9DB1538:2016-06-10:????-??-??::: [expires: ????-??-??]
When I run --list-packets I can see that the expiration is set to 27 years in future:
gpg --list-packets key.ascii
...
hashed subpkt 2 len 4 (sig created 2016-06-10)
hashed subpkt 9 len 4 (key expires after 27y145d0h0m)
Does it mean that gpg has a bug in handling 2016-06-10 + 27y145d?
Is it safe to assume that the date virtually never expires and assume it did not expire because the second column in the --with-colons argument is '-' and not 'e' (see https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=doc/DETAILS for the details of --with-colons output)
回答1:
Actually it IS Linux y2k issue. Even on Windows version of gpg. See this:
gpg --gen-key
...
Key is valid for? (0) 50y
Key expires at ????-??-??
Your system can't display dates beyond 2038.
However, it will be correctly handled up to 2106.
Is this correct? (y/N)
Yeap. Be aware that when you set expiration beyond 2038 it will impact gpg displaying expiration date and any software that relies on a proper expiration date being listed by gpg.
EDIT: Use gpg --with-colon --fixed-list-mode to print epoch time as an integer, which you can handle until 2106.
来源：https://stackoverflow.com/questions/52278411/gpg-with-colon-returns-as-the-expiration-date-linux-y2k-issue