search

voxpupuli / hiera-eyaml-gpg

GPG encryption backend for the hiera-eyaml module
MIT License
50 stars 33 forks source link

Track existing recipients #1

Open sihil opened 11 years ago

sihil commented 11 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

squiddle commented 6 years ago

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 commented 5 years ago

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.