Expired GPG Keys should not be ignored silently + there seems to be no gopass command to refresh life-extended keys

[leogott]

Summary

This problem cost me a day of productivity yday, and happened at least twice now, so it's dear to my heart.

When using gpg/gopass with 2+ recipients across multiple machines, be it for the star-use-case (team collaboration), or for a single-user multi-machine setup (my use-case), it is expected that a password-store will live for a couple of years, and possibly past the expiry date of a gpg-key. (I currently use a completely seperate key per machine, but this issue would likely persist with different subkeys per machine)

When the gpg-key for recipient L expires, and recipient A continues to use gopass, (adding secrets, updating secrets), any re-encrypted secrets will no longer be accessible to recipient L. Recipient A will not be notified when gopass omits recipients with expired keys, and recipient L will not be notified on sync that the password store now includes secrets that they will not be able to decrypt, or even that they need to refresh (gpg --edit-key, expire whatever) their key to continue using gopass.

Additionally the process to recover from this situation is kinda involved and not documented afaict?

Recipient L first needs to figure out that their key is expired, they can't just extend their key and follow it up with a gopass recipients --push-my-key-pls .
The easiest way I found to recover from such a situation is to remove oneself as a recipient gopass recipients rm <L>, manually delete the pwstore/.public-keys/ file, export your refreshed key with gpg -a --export <L> > L.pub.asc, share this file with recipient A, commit and sync the pwstore, have A gpg import the key and then gopass recipients add L to re-encrypt all the files.

edit: an easier way that might work (didn't test it), is for L to manually replace the .public-keys/L file with a prolonged key, sync, and A to reencrypt all secrets using gopass fsck --decrypt or similar.

If L notices their key has expired, or is about to expired, the process is less involved, but not obvious either.
IIRC they need to set a new expiry for their key, and then manually replace the pwstore/.public-keys/L file, and commit that change to the repo. If they only un-expire their key, they will not be notified that the commited public key has not been updated and will cause problems once past the expiry date.

Steps To Reproduce

0. have a pwstore in use with two recipients A and B
1. wait until recipient B's key expires
2. keep using gopass with A
3. attempt to use gopass with B

Expected behavior

When using most gopass commands, as well as when using gopass via the jsonapi, gopass should WARN the user in an appropriate manner, when their own key will expire in less than [a configurable timedelta, default 2 months]. This warning should include instructions on how to resolve the warning.

Also [configurable before/after/never, default 2 weeks before] a recipient's key expires, gopass should inform all other users on sync, audit, fsck and all commands that modify secret-files. The severity, idk. And recommended actions ("Please tell recipient X to update their key [link to docu on how] or remove recipient").

Once the users key has expired, gopass should notify the user, and recommend appropriate action. Possibly also inform them how to temporarily access older secrets without requiring immediate involvement of other recipients. (If that's possible. I think it is)

If the user's key is not about to expire, but their committed public key is (or vice-versa) gopass should notice and inform the user something's amiss. Preferably also how to fix it.

If the user is not a recipient of a password store, gopass should notice and inform the user.

Environment

• OS: Fedora and Pop!OS respectively
• OS version: [uname -a]
• gopass Version: gopass 1.15.11 (for L, 1.15.12 for A)
• Installation method: download from github

Additional context