Woo hoo! thanks, Patrick! On 04/22/2009 08:36 AM, Patrick Schoenfeld wrote: > Let's test if its a version 4 or greater key > Key is ok > Check for key expire stuff > Key has an expiration date of 2009-06-19 > 2012-05-31. Just a note on the weird-looking key expiration here: my primary key expires in 2012. The only bit that expires in june is my smaller authentication-capable subkey: 0 dkg@pip:~$ gpg --with-colons --list-key 0xd21739e9 | cut -d: -f 1,3,7,12 | grep '^[ps]ub' pub:4096:2012-05-31:scESCA sub:4096:2012-05-31:e sub:2048:2009-06-19:a 0 dkg@pip:~$ I suspect that the scripts used to generate these reports aren't used to dealing with keys with different expiration dates. Since the debian project probably currently only cares about OpenPGP usage for signing (signing .dsc and .changes files, bts messages, etc), the correct logic for this script is something like: * if the primary key has the "Signing" usage flag set (the lower-case "s" flag in field 12 above), use the primary key's expiration date. * if the primary key does *not* have the "Signing" flag, but one or more non-revoked subkeys do have the signing flag set, use: min(exp. of pubkey, max(exp. of non-revoked, sign-capable subkeys)) * if neither the primary key nor any non-revoked subkeys have the "Signing" flag set, the key should probably not be considered to be OK. If someone could to point me to the scripts, i can try to take a look at writing this logic in something more effective than pseudocode. Regards, --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature