Page MenuHome GnuPG
Create Task
Maniphest T4933

Incorrect expiration time of created subkey
Closed, WontfixPublic
Actions

Description

$ gpg2 --edit-key <keyid>
gpg (GnuPG) 2.2.20; Copyright (C) 2019 Free Software Foundation, Inc.
<...>
gpg> addkey
<...>
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 20220101T000000Z
Key expires at Sat Jan  1 03:00:00 2022 MSK
Is this correct? (y/N) Y
<...>
ssb  ed25519/<anotherkeyid>
     created: 2020-05-03  expires: 2021-12-31  usage: A

As you see, expire times differ.

BTW, there was no such problem when I created master key (expires: 2022-01-01).

Details

Version
2.2.20

Event Timeline

kuraga created this task.May 3 2020, 1:39 PM
• gniibe added a subscriber: • gniibe.May 4 2020, 4:16 AM

How does it show when you specify --full-time-strings (in UTC by ISO time format)?
I wonder if it is valid as data, but there is a problem of showing key(s).

kuraga added a comment.May 4 2020, 10:10 AM

I can't find such option.

• werner added a subscriber: • werner.May 4 2020, 11:13 AM

Right, we do have this option only in master (devel version).

• werner added a comment.May 4 2020, 11:25 AM
gpg -k --with-colons KEYID | awk -F: '$1=="pub" {print $7}'

gives the expiration time in seconds since epoch.

gpg -k --with-colons KEYID | awk -F: '$1=="pub" {print srtrftime ("%F %T", $7)}'

and that in ISO 8601 format

kuraga added a comment.May 4 2020, 11:36 AM
In T4933#134421, @werner wrote:
gpg -k --with-colons KEYID | awk -F: '$1=="pub" {print srtrftime ("%F %T", $7)}'

and that in ISO 8601 format

Ahaha, the fourth value:

$ gpg -k --with-colons <anotherkeyid> | awk -F: '$1=="pub" { print strftime("%F %T", $7) }'
2022-01-01 03:00:59
• werner triaged this task as Low priority.May 4 2020, 7:32 PM
• werner added a project: gnupg (gpg22).

So we are a minute off. The expiration timestamp is not stored in the key, instead the difference to the creation timestamp is give. This makes it a bit challenging to get it always right. Did you tried

gpg --quick-add-key

? The code paths are s lightly different. So if you need to have an exact expiration time; I would suggest to use that command. Here is the description from the man page

--quick-add-key fpr [algo [usage [expire]]]
       Directly  add  a  subkey  to  the  key identified by the fingerprint fpr.
       Without the optional arguments an encryption subkey is added.  If any  of
       the arguments are given a more specific subkey is added.

       algo  may  be any of the supported algorithms or curve names given in the
       format as used by key listings.  To use the default algorithm the  string
       ``default''  or  ``-''  can  be  used.  Supported algorithms are ``rsa'',
       ``dsa'', ``elg'', ``ed25519'', ``cv25519'', and other  ECC  curves.   For
       example the string ``rsa'' adds an RSA key with the default key length; a
       string ``rsa4096'' requests that the key length is 4096 bits.  The string
       ``future-default''  is  an  alias  for the algorithm which will likely be
       used as default algorithm in future versions of gpg.  To  list  the  sup‐
       ported  ECC  curves the command gpg --with-colons --list-config curve can
       be used.

       Depending on the given algo the subkey may either be an encryption subkey
       or  a  signing subkey.  If an algorithm is capable of signing and encryp‐
       tion and such a subkey is desired, a usage string must  be  given.   This
       string  is  either  ``default''  or  ``-'' to keep the default or a comma
       delimited list (or space delimited list)  of  keywords:  ``sign''  for  a
       signing  subkey,  ``auth'' for an authentication subkey, and ``encr'' for
       an encryption subkey (``encrypt'' can be used  as  alias  for  ``encr'').
       The valid combinations depend on the algorithm.

       The  expire  argument  can  be used to specify an expiration date for the
       key.  Several formats are supported; commonly the ISO formats  ``YYYY-MM-
       DD''  or  ``YYYYMMDDThhmmss'' are used.  To make the key expire in N sec‐
       onds, N days, N weeks, N months, or N years  use  ``seconds=N'',  ``Nd'',
       ``Nw'', ``Nm'', or ``Ny'' respectively.  Not specifying a value, or using
       ``-'' results in a key expiring in a reasonable  default  interval.   The
       values ``never'', ``none'' can be used for no expiration date.
kuraga added a comment.EditedMay 4 2020, 8:43 PM

So we are a minute off.

I don't understand. 2022-01-01 03:00:59 is 2022-01-01 03:00:00 + 1 minute - 1 second but both aren't 2021-12-31 even with timezone correction. Aren't, are they?

I don't have any problems with my keys.

I just thought it is a bug (of key generation). If no, feel free to close.

• werner added a comment.May 4 2020, 10:27 PM

Moscow time is 3 hours ahead of UTC, so we are talking about midnight 2022-01-01 00:00:00 aka 2021-12-31 24:00:00 . This is way we say we are 1 minute off. But I now see the problem, AWK's strftime needs another arg to to print in UTC. I am not so used strftime because I always use a my tool epoch2iso to convert Epoch times.

gpg -k --with-colons <anotherkeyid> | awk -F: '$1=="pub" { print strftime("%F %T", $7, 1) }'
kuraga added a comment.May 5 2020, 12:39 PM

2022-01-01 00:00:00 aka 2021-12-31 24:00:00

Ah, ok.

So,

  1. midnight issue,
  2. 1 minute / 59 seconds off.
kuraga added a comment.Jun 14 2020, 10:44 PM

Any news on this?

• werner closed this task as Wontfix.Jul 9 2020, 11:00 AM
• werner claimed this task.

I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.

kuraga added a comment.EditedJul 9 2020, 4:26 PM

gpg has code to make sure that a new key is at least one second newer than the previous generated.

@werner , does it mean "that's why keys' expiration times have to diffier"? Ok, that's something I can't talk talk about. (If only this doesn't violate RFCs.)

Ok. But:

  1. Why difference is 59 seconds instead of 1 second, for instance? And is it 59 seconds, or maybe it is non-constant or even random?
  2. Why GnuPG doesn't warn me that it uses expiration time which differs from inputed?

Thanks.

• werner added a comment.Jul 9 2020, 7:31 PM

Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.