Details
- Version
- 2.1
Related Objects
Event Timeline
If I create a key as follows, no expiry date is set:
$ gpg2 --faked-system-time 20100101T000000 --default-cert-expire 1y
--quick-gen-key 'Test Key <test@example.org>'
If I edit a key to add a new user ID under a faked system time as follows, the
new user ID does not receive the specified expiry date.
$ faketime 2010-01-01 gpg2 --homedir test --edit-key --default-sig-expire 2013-12-31
Which version of gnupg2 do you refer to? (On which platform?)
AFAIK 2.0.29 gpg2 does not have a --faked-system-time option.
Hi Bernhard,
I confirm the bug with gnupg-2.1.9 on Ubuntu 14.04.
I would have tried with 2.1.11 but failed to compile:
T2235
Best wishes
Jens
On 2016-01-28, Bernhard Reiter via BTS wrote:
Bernhard Reiter <bernhard@intevation.de> added the comment:
Hi Jens,
which version of gpg2 on which platform did you try this?
nosy: +bernhard, lechten
GnuPG's BTS <gnupg@bugs.g10code.com>
<T2118>
Jens,
thanks for the report. Now I can classify this as GnuPG "modern" issue. :)
Bernhard
This has nothing to do with faking time one way or another.
You are reporting two problems. In the future, please create two issues.
I agree with your first problem, even though there is additional syntax for specifying the
expiration date with --quick-gen-key. This is easy to fix.
Your second problem is less clear. First of all, your command line makes no sense. --
default-sig-expire only affects signatures over data. Furthermore, user ids do not
expire, merely the (self-)signatures may do so. Do you want that?
On 2016-07-19, Justus Winter via BTS wrote:
Your second problem is less clear. First of all, your command line makes no
sense. --
default-sig-expire only affects signatures over data. Furthermore, user ids
do not
expire, merely the (self-)signatures may do so. Do you want that?
Back then I was trying to generate test keys (for GnuPG integration
in Gnus/Emacs). I was under the assumption that user IDs can
expire. At least code in Gnus has tests to ignore revoked and/or
expired UIDs.
Also without knowing more about this, in doc/DETAILS I see the
following, which seems to mention UID expiration.
--8<---------------cut here---------------start------------->8---
- Field 7 - Expiration date
Key or UID/UAT expiration date or empty if it does not expire.
--8<---------------cut here---------------end--------------->8---
The document you cite also states that UID/UAT lines only use field 10.
Also, neither UID nor UAT packets encode an expiration date [0], the way an UID/UAT can expire
is that the self-signature expires [1].
0: https://tools.ietf.org/html/rfc4880#section-5.11
1: https://tools.ietf.org/html/rfc4880#section-5.2.3.3
I do no longer agree with your first problem. Key expiration is different from signature
expiration, the way to quickly generate a key that expires in one year is:
$ g10/gpg --quick-gen-key quick_test - - 1y
I guess one could argue that if one specifies --default-cert-expire=X when adding an uid, that
the self-signature for the new uid should expire. But to be honest, I doubt that this matches
user expectations.
What would be the use case really? I know that I'll lose access to that mail address in X years
and hence want my uid to expire then.
lechten: I agree with justus' evaluation. Further we can't change the sematics
of --default-cert-expire in the way you want that; it would not be compatible.