Key expires at ... 1971
wk at gnupg.org
Fri Jun 6 10:07:12 CEST 2008
On Thu, 5 Jun 2008 19:35, dshaw at jabberwocky.com said:
> changing it reasonable. However, we can do a lot better than
> translating "99y" into a key that is instantly expired. Even
> returning an error there would be an improvement.
The question is what to display then. We would need to change all
output to either display the correct date or a string like "expires
after 2037". That would be okay for humans but not for machine parsing.
In --with-colons mode (along with theat --fixed-list-mode) we display
seconds since Epoch, so that is not a problem - we need to check that we
print them correctly.
We could also settle for 21040501T141516 in the --with-colons output as
described by DETAILS:
Note that the date is usally printed
in seconds since epoch, however, we are migrating to an ISO
8601 format (e.g. "19660205T091500"). This is currently
only relevant for X.509, A simple way to detect the format
is be scannning for the 'T'.
At least gpgme handles both formats correct.
> Amusingly enough, GPG used to handle this a bit better than it does
> now. A few years ago, a 99y value would at least be placed correctly
> in the expiration subpacket. It would fail when *using* the key, but
Yet another missing regression test ;-).
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
More information about the Gnupg-devel