Track existing recipients

[sihil]

Edit mode for GPG should track existing recipients and re-encrypt to the same set of keys.

This can't be done for two reasons.

1. We don't track individual blocks uniquely and
2. It isn't possible to get the recipient list out of GPGME as recipients is not implemented in the DecryptResult object.

If these two are fixed then we can make this work.

[sihil]

Part 1 of this is fixed, so we just need access to the recipients field in gpgme. Not a priority and I think that the recipients file makes this less helpful now. Might investigate in the future if people want it.

[robinbowes]

I want it!

I'd like to be able to check the recipient list of an encrypted block to ensure it is encrypted with the correct keys.

[RoUS]

Ditto. We've got a lot of different people storing encrypted secrets (GPG plugin), and while the operations team doesn't need to know the secrets themselves, we would like to be able to vet the recipients for each cryptotext value.

[tpdownes]

What is the status of this particular enhancement? My goal is fairly simple: to encrypt all variables fir the same set of recipients, although staff come and go, so that set can change with time. Right now, the only way I see to do that is to eyaml edit every file, remove the number in parentheses, and re-save.

I care less about the edge-case of a recipient revoking/expiring their key and more about minor additions or removals of recipients. Seems like there should be a smarter way than what I am doing which isn't very automatable. Maybe I can script something with eyaml decrypt -e?

@RoUS has a much more interesting though similar use case.

[sihil]

@tpdownes I think you should be able to use the recrypt action for your use case IIRC - this is explicitly designed for rolling keys.

[tpdownes]

@sihil And now I see that option pleasantly listed in --help. Thanks!

[squiddle]

just in case someone is still interested in this:

the 2nd part of the original issue report is also fixed

the recipients are nowadays available in the DecryptResult from gpgme

[ghoneycutt]

This type of functionality should not assume there is only one list of recipients. I generally use this in environments where there are multiple recipient lists as different teams want to encrypt data to which other teams should not have access.