Repository: gopasspw/gopass

Issue #2015: Add a `--reencrypt` option to `fsck`
Created: 2021-10-21T10:46:52Z
It can happen that we are doing a "key rotation" or have changed some things related to PGP that require us to fully re-encrypt our store.
Currently the only process to do so it adding a dummy recipient and then removing it.
This is not really desirable as it can lead to side effects such as committing secrets with a "weaker" key or so to our pw store.
Ideally we should be able to use fsck --reencrypt in order to decrypt all secrets and "re-encrypt" it with the current set of recipients.
This would also help solving issues such as "My process failed while I was adding a recipient", "I ^C Gopass in the middle of the removal of a recipient" or other things like that and would fit nicely under fsck responsabilites, IMO.
This would also have helped for example in #1977 when it was needed to fully re-encrypt the store using a downgraded PGP version because the latest PGP version wasn't being properly supported and cross-compatible for our usecase.
This also help with "expired subkeys": I can just add a new subkey to my key and "re-encrypt" the whole store.
So it would relate to: #1969, #1107, #1430
What it should do: re-encrypt in place all secrets for the current set of recipients, using the "main" encryption subkey of a key (or the specified subkeys) for each recipient, and then commit/push/sync the whole as per existing config.

Duplicate issue #1918: Check all the keys in .gpg-id are valid before adding a new key
Created: 2021-05-04T10:11:08Z
Summary
There are two things here:

This is not a bug, but an usability issue. When adding a new key with gopass recipients add --store <store> <user_id> the secrets will be re-encrypted for every key in .gpg-id. If one of this keys is expired the encryption will fail.
This I think it is a bug, if the encryption failed on the previous step, the new key will be added to .gpg-id even though it can't decrypt anything, running gopass fsck won't fix the issue.

Steps To Reproduce
I had this issue with a key that actually expired, I suppose these steps can reproduce the issue:

Create a new key pair
Add it to the password store and encrypt a secret with it
Edit the previous key and set the expiration in the past
Create a second key pair
Try to add the non-expired key to the keystore

Expected behavior
A nice error message saying that one of the keys is expired, and user intervention is necessary. Either the key has to be removed from the password store, or the owner of the key has to update the expiration.
Environment

OS: Fedora
OS version: Linux .. 5.11.15-200.fc33.x86_64 #1 SMP Fri Apr 16 13:41:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
gopass Version: gopass 1.8.6 (d5b0d3b 2021-01-27 21:11:07) go1.15.6 linux amd64
Installation method: compiled

Additional context

Closing comment (2021-10-21T11:19:59Z): We should at least support using an expired key to add a new recipients.
Todo:

 Add a test case for this
 Add a warning when there is such a thing, and proper documentation about what is possible to do in that case (namely: extend the private key expiration date OR remove the expired key and add a new key with a expiration date in the future)
 Add a flag to "ignore" expired keys upon re-encryption as long as there are still valid keys in the recipient list (or maybe provided we are working with a non-expired subkey related to the same master key as the expired key?)
 Make sure we cannot add or create or generate new secrets if we have an expired key: Warn the user they need to add a new non-expired key and remove the expired key.

Somewhat related to #2015 too.