Feature Request: Ability to use edit without the private key

[eriksw]

It'd be nice to be able to use eyaml edit for adding new values to be encrypted (by adding new DEC::.. items) to a file even when you don't have the private key and won't be able to see the decrypted values that already exist.

Alternatively, it'd be useful if there was function that can be run against a file that will encrypt and replace any DEC:: instances it finds in the file. (My thinking is to make this part of a pre commit hook.)

[ardichoke]

+1 for the ability to edit and add new values without the private key. We edit hieradata on our workstations a lot, and the pubkey is in our repos to make this more easy, but obviously the privkey is not.

[rnelson0]

Just talking this out to see how it would work. We'll imagine we have an existing hiera file with an encrypted value:

---
mysql::server::root_password    : ENC[PKCS7,LONGSTRING]

And the goal is to add the key mysql::server::backuppassword with another encrypted value.

Current functionality, requires private and public key.

1. eyaml edit mysql.yaml
2. Existing key is decrypted

---
mysql::server::root_password    : DEC(1)::PKCS7['actualpassword']!

3. New key is added

---
mysql::server::root_password    : DEC(1)::PKCS7['actualpassword']!
mysql::server::backup::backuppassword    : DEC::PKCS7['newpassword]!

4. File is saved, contents are encrypted

---
mysql::server::root_password    : ENC[PKCS7,LONGSTRING]
mysql::server::backup::backuppassword    : ENC[PKCS7,LONGSTRING]

---

Proposed functionality, where no private key is available, suggests that an edit function will not decrypt the key and display 'as is'.

1. eyaml edit mysql.yaml
2. Existing key is NOT decrypted

---
mysql::server::root_password    : ENC[PKCS7,LONGSTRING]

3. New key is added

---
mysql::server::root_password    : ENC[PKCS7,LONGSTRING]
mysql::server::backup::backuppassword    : DEC::PKCS7['newpassword]!

4. File is saved, contents are encrypted

---
mysql::server::root_password    : ENC[PKCS7,LONGSTRING]
mysql::server::backup::backuppassword    : ENC[PKCS7,LONGSTRING]

---

The significant difference is the state of the file after step 1, where the key is not decrypted, and after step 3, where a mix of encrypted and decrypted strings are present. On a subsequent edit, the file would look as it does after step 4, never replacing ENC[] strings with DEC::PKCS7[]! strings.

I just want to make sure that I am accurately understanding the proposal before anyone works on implementing it.

[ardichoke]

I cannot speak for anyone else, but that workflow sounds correct to me.

[benjunmun]

I've submitted a pull request for a conservative version of this feature - default behavior remains the same, and I've added a flag to skip the decryption step. Let me know if I should make any changes to this, especially if it's more desirable to automatically fall back to this behavior if there is no private key.