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?

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.

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 @@

   return G10ERR_TIME_CONFLICT;
}

• 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.