eyaml incorrectly errors when it cannot decrypt a key

[ghoneycutt]

I am using your software in an environment where multiple people are creating encrypted entries and I am not meant to be able to read their encrypted entries. I would expect that any entries that can be decrypted would be and the rest would just show up encrypted, as they are.

What actually happens is that an error is thrown.

[gpg] Fatal: Failed to decrypt ciphertext (check settings and that you are a recipient)
[hiera-eyaml-core] Decryption failed

$ gem list | grep eyaml
hiera-eyaml (2.1.0)
hiera-eyaml-gpg (0.6)

Here's a trace

[hiera-eyaml-core] /Users/gh/.rvm/gems/ruby-2.1.8/gems/gpgme-2.0.12/lib/gpgme/ctx.rb:428:in `decrypt'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-gpg-0.6/lib/hiera/backend/eyaml/encryptors/gpg.rb:183:in `decrypt'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:15:in `encrypted_value'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:80:in `create_enc_token'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:100:in `create_token'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/parser.rb:71:in `parse_scanner'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/parser.rb:74:in `parse_scanner'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/parser/parser.rb:36:in `parse'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/subcommands/edit.rb:74:in `execute'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/lib/hiera/backend/eyaml/CLI.rb:46:in `execute'
                   /Users/gh/.rvm/gems/ruby-2.1.8/gems/hiera-eyaml-2.1.0/bin/eyaml:21:in `<top (required)>'
                   /Users/gh/.rvm/gems/ruby-2.1.8/bin/eyaml:23:in `load'
                   /Users/gh/.rvm/gems/ruby-2.1.8/bin/eyaml:23:in `<main>'
                   /Users/gh/.rvm/gems/ruby-2.1.8/bin/ruby_executable_hooks:15:in `eval'
                   /Users/gh/.rvm/gems/ruby-2.1.8/bin/ruby_executable_hooks:15:in `<main>'

I think this correlates to https://github.com/sihil/hiera-eyaml-gpg/blob/master/lib/hiera/backend/eyaml/encryptors/gpg.rb#L184 though I'm unsure as to how to fix this.

[sihil]

Can you give some context to when you are experiencing this?

As you might imagine, returning an encrypted value in a situation where you'd like the decrypted value or a clear failure would potentially be surprising or problematic (you could end up installing an encrypted certificate on a server which would then fail to start correctly).

Within edit mode it does make a certain amount of sense to ignore decryption failures and indeed this should be possible.

Further clarification would help me decide if and how to change the behaviour here.

[ghoneycutt]

Related to voxpupuli/hiera-eyaml#146

Basically we have multiple teams of people that want to encrypt data that is not necessarily meant to be decrypted by others. This is the attraction of using gpg instead of pre-shared secrets.

[lawrencegohar]

I'd like to chime in that this is a serious pain point for us as well. Hiera data that doesn't pertain to a particular node causes hiera-eyaml-gpg to throw a GPGME::Error::DecryptFailed. This hinders local development, for example, because {global,location,environment}-specific secrets which can be overridden for local development via hiera cause this gem to ignore the specific data that it can decrypt. To make an analogy, this is like giving a friend my keys to water my plants while I'm on vacation. I don't expect him to give up simply because the car key doesn't open the front door to the house.

Perhaps a good compromise would be to ignore DecryptFailed errors unless nothing can be decrypted; e.g. - if the parameter in question ends up nil after the run completes. This would be forgiving enough to accommodate this and similar use cases, while failing when it has no other options to try.

[alexjfisher]

Would voxpupuli/hiera-eyaml#215 help at all? AFAICT, with that change at least data from parts of the hierarchy that wouldn't ever end up in the final merged hash wouldn't need to be decrypted.

[ghoneycutt]

I don't think that applies because there could be multiple teams (recipient lists) editing values in the same hiera data file.

[JonLoesch]

Somebody posted in the related issue, reposting here:

You can use eyaml edit --no-decrypt

Not sure if you're still on this issue -- It's been years since I've worked with hiera and I don't have the setup to test it right now. Also, I feel like this is not attempting to decrypt at all rather than ignoring failures to decrypt which may or may not help your use case. In any case, I'm just passing the message along. Cheers!