Key expires at ... 1971

[Werner Koch]

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 ;-).


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.