Page MenuHome GnuPG

EXPKEYSIG doesn't catch primary=expired, subkey=valid
Closed, ResolvedPublic


Following some investigation from Peter Palfrader in Debian bug #489225 it
seems, that the case primary key = expired, subkey still valid doesn't lead to
an EXPKEYSIG status type using --fd-status. Is this intended or a missing catch?


Due Date
Jan 15 2010, 1:00 AM
External Link

Event Timeline

dleidert set Version to 1.4.9.
dleidert set External Link to
dleidert added a subscriber: dleidert.

I think that if the primary key is expired, the subkeys should be treated as
expired as well. The only thing that makes the subkey valid in the first place
is the binding signature - which was issued by the expired primary key.

I have not checked the code, but it seems plausible not to check the subkeys
once the primery key has been marked as expired. Checking the subkeys would
spend useless CPU cycles.

However, we can catch that in GPGME and flag all subkeys as expired in the
primary one expired. Thus I change the category to GPGME.

Marcus, can you please check that?

werner removed a project: gnupg.
werner added a project: gpgme.
werner removed Version.
werner added a subscriber: marcus.
marcus removed a project: gpgme.

I don't think it is wise to change results returned from the backend engine too
much in GPGME. It makes it more confusing to see what's going on by giving
different results for essentially the same operation.

This is even more important for operational results such as signature
expiration. We certainly don't want different definitions of what attributes a
signature has (one in gpg, one in GPGME), and the original report is about gpg's
definition of EXPKEYSIG. Reassigning back to gpg, please handle it there.

werner set Due Date to Jan 15 2010, 1:00 AM.

Fixed in all branches. rev. 5236. Patch for 1.4.10 below:

  • g10/sig-check.c (revision 5165)

+++ g10/sig-check.c (working copy)
@@ -209,7 +209,11 @@

  • if( pk->expiredate && pk->expiredate < cur_time ) {

+ /* Check whether the key has expired. We check the has_expired
+ flag which is set after a full evaluation of the key (getkey.c)
+ as well as a simple compare to the current time in case the
+ merge has for whatever reasons not been done. */
+ if (pk->has_expired || (pk->expiredate && pk->expiredate < cur_time)) {

char buf[11];
if (opt.verbose)
 log_info(_("NOTE: signature key %s expired %s\n"),

If you want to test this the new --faked-system-time option in trunk should come
handy (e.g. --faked-system-time 20091231T120000)

2.0.14 has been released - closing.

werner removed a project: Restricted Project.