hiera-eyaml icon indicating copy to clipboard operation
hiera-eyaml copied to clipboard

Ability to edit files without being able to decrypt them

Open JonLoesch opened this issue 9 years ago • 3 comments

The short version of this feature request is that I would like to be able to use the "eyaml edit" command to edit files if I have all the required public key(s), even if I don't have the private key(s). The behavior should be that anything eyaml is unable to decrypt and show it should just leave encrypted. Essentially, this would allow you to change / add encrypted data even if you don't necessarily have rights to view it.

In more detail: my use case is that I would like to have each host on our footprint to have an individual GPG key, so that a compromise of one server will not affect other servers. The hiera files are split out by hostname already, so each file is encrypted using different public keys. Our development team will have access to all the public keys, but not necessarily the private keys. They are able to run eyaml encrypt, but not eyaml decrypt. But the eyaml encrypt command is a bit clunky for us when we have many passwords embedded in a single yaml file. so I'd really like to be able to use the "eyaml edit" command, if possible.

A bit more (mostly irrelevant) backstory here: https://github.com/sihil/hiera-eyaml-gpg/issues/25

JonLoesch avatar Mar 03 '15 16:03 JonLoesch

+1 This seems like a critical feature for any widespread use of hiera-eyaml. How are you supposed to keep your private key secure if every developer that needs to add/edit encrypted values needs to pass the private key around? I want the private key to exist only on my puppet masters and not on every dev's box.

cheethoe avatar Mar 10 '16 19:03 cheethoe

You can use eyaml edit --no-decrypt

mxey avatar Oct 10 '22 14:10 mxey

Ah. There's a technical difference between not erroring on a failed decrypt and not attempting a decrypt at all. I'm sure this would work for some use cases though, so good point.

I haven't worked in heira in years and I'm not really in a position to judge whether this issue should still be open or not, so I'm not going to do anything. If someone else wants to close it out go for it. There is interestingly enough an orphaned branch of development from 2015 on this, no idea how complete it is.

JonLoesch avatar Oct 13 '22 22:10 JonLoesch