Hi,

I have:
3.4.3 (Puppet Enterprise 3.2.0)
Welcome to eyaml 2.0.2
CentOS release 6.5 (Final)

hiera.yaml

:backends:

• eyaml
• yaml
  :hierarchy:
• defaults
• "%{clientcert}"
• "%{environment}/jdk"
• "%{environment}/jboss"
• "%{environment}/mathematica"
• global

:yaml:
:datadir: /etc/puppetlabs/puppet/hieradata
:eyaml:
:datadir: /etc/puppetlabs/puppet/hieradata
:pkcs7_private_key: /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem

levent.eyaml

levent_parent_upload_dir : /data/puppet
levent_installation_file : levent.sh
levent_target_dir : /opt/levent
levent_activation_key : levent
levent_test_eyaml_levent: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAKN5vaOYzrAhBZQZJdpNj0p2QcM2EUq4c8Sqz
UcV91nkKm7O9i0s4VAFu2ueH0sZwLG6bqVVk2ZWt/rnDc5tdyMQhJOVwhxxY
WWwJLrPqyByuMQTVF2MeXsO/PU5UJ5TEiZuq8x50O2ZJCHXL+TuiU10xPEOn
kbI6vNBfYo6/axhOuDW+UN+KBQV7QbC14FoJDR/Q3WJ8LEgBHnAZvI3U13jU
MecSCh8kK6/YP1223pTgE494TwaJ5yOWe1wOAxbbEDlie/1qr5XGX7qjMjZX
FULCVew/A65ZaajiWMMzV0KJj4r5oWeaTLgstpOvCSr4k1vvbaAPfDCXRU6E
6AloyjA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBOJv9YAF5XNmbfHKFt
eJObgBCIy5NWOyDa0DbVaYSWa8M6]

puppet agent is installed on a different host without hiera-eyaml.
It looks like eyaml does not work since it should by default look at .eyaml files.

When I configure it to read yaml files, password will not be decrypted.

When I call, eyaml edit levent.eyaml, I can see the password as stated in documentation.

Only from puppet-hiera will it not work, any ideas?

Hi,

Just updated to 1.3.6.
At the weekend I was working on supporting re-encryption based on 1.3.4. I'm using hiera-eyaml-gpg and periodically need to encrypt my whole hieradata to support staff changes, each with their own key. We have dozens of hiera files, with hundreds of encrypted keys. The enc blobs must change to cover changes in recipient public keys (GPG plugin).

As I'm a ruby noob I hacked the edit/save to take a --force option to save on unchanged, simply bypassing the "No changes" exception. I set EDITOR=cat to avoid an editor. That was hackish but worked as POC.

I like the new parser, and tests. It's clearly much nicer to support recrypt as a first order function via the new parser than abusing EDITOR. What's different is now the blobs don't pass through encryption just because the file changes. IMO this is a good thing, in the normal case I don't want to pollute a file full of changes when only one item changes. However I still need a --recrypt-all type option to cover my recipient change case.

I will reply to myself in the next few hours if I figure this out.

Thanks for reading,

I am trying to use hiera-eyaml and have followed the README instructions.

eyaml seems to work, I can encrypt and decrypt files and passwords.

I can also use hiera -c to get at an encrypted value like so:

hiera -c /etc/puppetlabs/puppet/hiera.yaml rootpwd

But when running this simple test module it fails with cannot find the data item rootpwd defined in hieradata/defaults.eyaml.

class test {
$test = hiera('test')
$rootpwd = hiera('rootpwd')
notify { "Test: ${test}": }
}
If I just have the test variable defined in defaults.yaml it works fine. So it cannot find the defaults.eyaml file.

Here is my hiera.yaml:

:backends:

• yaml
• eyaml
  :hierarchy:
  • defaults
  • "%{clientcert}"
  • "%{environment}"
  • global
    :yaml:
    :datadir: /etc/puppetlabs/puppet/modules/hieradata
    :eyaml:
    :datadir: /etc/puppetlabs/puppet/modules/hieradata
    :pkcs7_private_key: /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
    :pkcs7_public_key: /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem

And my defaults.eyaml file:

rootpwd: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQE ...]
Any hints will be greatly appreciated.

I am running Puppet Enterprise 3.1.0 on Ubuntu 12.04.

Hi, I tried to implement this in my puppet code and I'm getting following error

Debug: hiera(): [eyaml_backend]: Lookup called for key value-encryption-test
Debug: hiera(): [eyaml_backend]: Processing datasource: /etc/puppet/hieradata/vm.local.eyaml
Error: Could not run: (): could not find expected ':' while scanning a simple key at line 19 column 1

And I assume it's about *.eyaml file which on 19 line has

value-encryption-test: >
ENC[Gx7ys+HTjAgPJU7y4xHQloTy8YvFvKIU7pf4Hf8BcKefWbCV2AkxVnUP+NNC
NKOsgVpBJhZXx1acULhJg0y7YKvm2e6XjEZPqulb1iU8s5XwVK0HjG0YMsLd
6Bg2wU6lEB/BIVjzjorGmj4RRGW9ZPKTew0LCjFzo7jfTIbvOC4MC0n+OyjV
RbXzJoQ8/kQMT/jrnSLRxa9W1xrsEQQqX340A/iKb1O+Lf4FRaby069V2imR
EZVSWEvRb2jeEBUb2jrBKB2cXbOBGin2zIZ6ty6bS3+VM1nuC+AYzYTq6wkv
wL2mgBYin/JWlSyZ2LRlzB9h3xdZFoVvmzMHSXSJfA==]

I'd appreciate any ideas on what could be wrong here.

Thanks

If you have any empty .eyaml files you get strange errors on puppet runs:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method `empty?' for false:FalseClass at /etc/puppet/manifests/nodes_something.pp:3 on node hostname.coolplace.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

[[email protected] ~]# hiera -c /etc/puppet/hiera.yaml root_pw_hash
/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:58:in `parse_encryption_scheme': undefined method `default_encryption_scheme' for Hiera::Backend::Eyaml:Module (NoMethodError)
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:43:in `execute'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `gsub'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `execute'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:101:in `decrypt'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:98:in `gsub'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:98:in `decrypt'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:64:in `parse_answer'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:31:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:68:in `datasources'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `map'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `datasources'
        from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml_backend.rb:18:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:182:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `each'
        from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `lookup'
        from /usr/lib/ruby/site_ruby/1.8/hiera.rb:64:in `lookup'
        from /usr/bin/hiera:220

Could this have something to do with having two backend classes? (Hiera::Backend::Eyaml and Hiera::Backend::Eyaml_backend)

I'd like to improve the edit mode, and pave the way for the gpg module.

I think it's quite important that when editing a EYAML file that we do not re-encrypt blocks that have not been edited (this will make diffs work much better). In order to achieve this, it must be possible to uniquely identify a block in the edit mode and compare it later.

I was thinking something like DEC(4b2a562f)::GPG[content goes here]! Duplicate ID's will fail when re-encoding (if people copy and paste) and throw the user back into their editor.

eyaml will store the original (encrypted and decrypted) data blocks for each tag in memory whilst editing. It can then compare them during re-encryption and reuse anything that hasn't changed.

In addition, GPG recipients are encoded in the source encryption and should be carried over when re-encrypted unless overridden. This can be implemented either by hooking onto the unique tags or by adding the recipients directly (I prefer the former).

It should be a low impact change as only the transient decrypted format is being modified.

This was included in Hiera 1.3.3 and should increase performance when traversing the hierarchy. I will try to do the change myself but I can't Ruby ;).

See puppetlabs/hiera@37bb93b

Currently when trying to encrypt files it looks in ./keys/ for the private/public keys.

This cause problems with changing directory and trying to edit files without specifying them with -r and -r.

This could be defined in a $HOME/.eyaml.conf file or similar? Or globally in /etc/?

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec,

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Even for projects that already specify a license, including a license in your gemspec is a good practice, since it is easily
discoverable there without having to check the readme or for a license file.

For example, there is a License Finder gem to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough
issue that even Bundler now generates gems with a default 'MIT' license.

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file),
github has created a license picker tool.

In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally
looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :).

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue and let me know. In either case, I'll follow up. Thanks!

p.s. I've written a blog post about this project

Error: Parameter key failed on Ssh_authorized_key[deploy_key]: Key must not contain whitespace: AAAAB3NzaC1yc2E(..)

And I'm pretty much sure I'm not inserting whitespace anywhere, and the value presented with the error exactly matches encrypted value.

Any ideas on what's going wrong?

Thanks,
Piotr

I think the permissions should be 640 by default? perhaps it should also try change the ownership to puppet:puppet if that user exists on box otherwise root:root?

# eyaml -c
/etc/hiera/keys/private_key.pem created.
/etc/hiera/keys/public_key.pem created.
# ls -l
total 8
-rw-r--r-- 1 root root 1675 Aug 14 10:45 private_key.pem
-rw-r--r-- 1 root root 1050 Aug 14 10:45 public_key.pem

I just started evaluating hiera-eyaml and hit a glitch. It seems that any attempt to read a hash in an eyaml file using hiera_hash(), produces an error:
"Error 400 on SERVER: Resolution type is hash but parsed_answer is a Hash" The error occurs even if the hash does not contain any encrypted values. One more detail:

• hiera( 'somehash' ) works fine
• hiera_hash( 'somehash' ) fails

I'm using heira-eyaml 2.0.0 on puppet 3.2.3. Has anyone seen this before?

The following code snippets should reproduce the problem:

file: my_hiera.eyaml
somehash:
foo: this is just a string

code:
$a = hiera( 'somehash') # This succeeds
$b = hiera_hash('somehash') # This fails

Trying to use hiera-eyaml 1.3.2 installed from rubygems
Command line decryption is working fine:

eyaml --pkcs7-private-key /root/hiera_private_key.pem -k /root/hiera_public_key.pem -d -f /vagrant/hieradata/common.eyaml 

But when trying to retrieve file with hiera receive following exception:

hiera -d -c /vagrant/hiera.yaml gerrit::mysql_password role='gerrit'

DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Lookup called for key gerrit::mysql_password
DEBUG: Tue Sep 03 14:03:59 +0200 2013: Cannot find datafile /vagrant/hieradata/roles/gerrit.eyaml, skipping
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Processing datasource: /vagrant/hieradata/common.eyaml
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Data contains valid YAML
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Key gerrit::mysql_password found in YAML document
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Attempting to decrypt: gerrit::mysql_password
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: pkcs7_private_key = /root/hiera_private_key.pem
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: pkcs7_public_key = /root/hiera_public_key.pem
DEBUG: Tue Sep 03 14:03:59 +0200 2013: [eyaml_backend]: Setting: datadir = /vagrant/hieradata
/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:58:in `parse_encryption_scheme': undefined method `default_encryption_scheme' for Hiera::Backend::Eyaml:Module (NoMethodError)
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:43:in `execute'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `gsub'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml/actions/decrypt_action.rb:42:in `execute'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:101:in `decrypt'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:98:in `gsub'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:98:in `decrypt'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:64:in `parse_answer'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:31:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:68:in `datasources'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `map'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:66:in `datasources'
    from /usr/lib/ruby/gems/1.8/gems/hiera-eyaml-1.3.2/lib/hiera/backend/eyaml_backend.rb:18:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:182:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `each'
    from /usr/lib/ruby/site_ruby/1.8/hiera/backend.rb:179:in `lookup'
    from /usr/lib/ruby/site_ruby/1.8/hiera.rb:64:in `lookup'
    from /usr/bin/hiera:220

my hiera.yaml looks like:

:hierarchy:
...
:backends:
  - eyaml
  - yaml
:yaml:
  :datadir: '/vagrant/hieradata'
:eyaml:
  :datadir: '/vagrant/hieradata'
  :pkcs7_private_key: /root/hiera_private_key.pem
  :pkcs7_public_key:  /root/hiera_public_key.pem

Same stuff worked for hiera-eyaml 1.1.4

When I perform a puppet run the decryption of eyaml data fails with the following error.

[vagrant@//redacted hostname// home]$ sudo puppet agent -t --noop
<< some puppet run output >>
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Permission denied - /var/lib/puppet/ssl/private_keys/private_key.pkcs7.pem at /etc/puppet/modules/users/manifests/init.pp:39 on node //redacted hostname//
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

If private_key.pkcs7.pem is chmod'ed to 404, the same error is thrown for public_key.pkcs7.pem until it is chmod'ed to 404, as well.

Permissions on the files when failure occurs are as follows.

-sh-4.1# readlink -f private_key.pkcs7.pem && ll private_key.pkcs7.pem
/var/lib/puppet/ssl/private_keys/private_key.pkcs7.pem
-r-------- 1 root root 1675 May 12 21:09 private_key.pkcs7.pem

-sh-4.1# readlink -f public_key.pkcs7.pem && ll public_key.pkcs7.pem
/var/lib/puppet/ssl/public_keys/public_key.pkcs7.pem
-r-------- 1 root root 1050 May 12 21:09 public_key.pkcs7.pem

I can decrypt the eyaml data via the command line, as follows.

[vagrant@//redacted hostname// ~]$ sudo hiera -c /etc/puppet/hiera.yaml root_password
//redacted, but correct, root password is displayed//

If I run the command without sudo I receive a read permission denied error on the private key file, as expected. However, curiously, running 'puppet agent -t' as root gives the same ERROR 400 during catalog compilation.

It is difficult to understand why read permissions for 'other' are needed when everything should be running as root.

Encrypting a string with a leading dash fails with "unknown argument", e.g. running

eyaml -e -s '-test'

fails with:

Error: unknown argument '-t'.
Try --help for help.

I just started evaluating hiera-eyaml and hit a glitch. It seems that any attempt to read a hash in an eyaml file using hiera_hash(), produces an error:
"Error 400 on SERVER: Resolution type is hash but parsed_answer is a Hash" The error occurs even if the hash does not contain any encrypted values. One more detail:

• hiera( 'somehash' ) works fine
• hiera_hash( 'somehash' ) fails

I'm using heira-eyaml 2.0.0 on puppet 3.0.1. Has anyone seen this before?

The following code snippets should reproduce the problem:

file: my_hiera.eyaml
somehash:
foo: this is just a string

code:
$a = hiera( 'somehash') # This succeeds
$b = hiera_hash('somehash') # This fails

eyaml createkeys --help outputs the following

   --pkcs7-private-key <s>:   Private key directory (default: ./keys/private_key.pkcs7.pem)
    --pkcs7-public-key <s>:   Public key directory (default: ./keys/public_key.pkcs7.pem)

The word "directory" is misleading, since what it actually wants is the full path to a file (as the default example shows).

Hello, first off I am running:
CentOS 6.5
puppet-3.4.3-1.el6.noarch
puppet-server-3.4.3-1.el6.noarch

gem list
hiera (1.3.2)
hiera-eyaml (2.0.1)
highline (1.6.21)
json (1.5.5)
json_pure (1.8.1)
stomp (1.2.2)
trollop (2.0)

My hiera.yaml looks like this:

---
:backends:
 - eyaml
 - yaml

:yaml:
  :datadir: /etc/puppet/environments/%{environment}/hiera/

:eyaml:
  :datadir: /etc/puppet/environments/%{environment}/hiera/
  :pkcs7_private_key: /etc/puppet/secure/private_key.pkcs7.pem
  :pkcs7_public_key: /etc/puppet/environments/master/public_key.pkcs7.pem

:hierarchy:
  - %{::clientcert}
  - %{::environment}
  - %{::stage}
  - %{::location}
  - common

:logger: console

When I have .yaml files (and no eyaml files) in my hiera dir I get this error:

Error 400 on SERVER: Error from DataBinding 'hiera' while looking up 'repo::domain::url': undefined method `read_file' for #<Hiera::Filecache:0x7f9b1aae1b60 @cache={}> on node bla

If I either:
rename .yaml .eyaml *.yaml

OR if I disable eyaml from the hiera.yaml, everything works as it should.

Here is a --trace:
https://gist.github.com/shawn-sterling/9774519

If there is anything I can do to help further debug this issue let me know.

Have a good day.

-Shawn

While upgrading to eyaml 2.0.1 and puppet 3.4.3 using RPMs I encountered installation bug #80. While deciding how to work around this I uncovered a hidden difference between hiera and rubygem-hiera.

rubygem-hiera-1.3.2-1 works
hiera-1.3.2-1 fails with the error (see bottom) which implies that eyaml couldn't find the encrypted value.

This may be a manifestation of bug #82 bcuz I have both eyaml and yaml backends enabled.

My system is:
CentOS 6
puppet-3.4.3-1.el6.noarch
puppet-server-3.4.3-1.el6.noarch
fastthread (1.0.7)
hiera (1.3.2) --- in either hiera or rubygem-hiera incarnation
hiera-eyaml (2.0.1)
highline (1.6.20)
json (1.4.6)
json_pure (1.8.1)
rack (1.1.0)
rake (0.8.7)
trollop (2.0)

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template exim/tls-certificate.erb:
Filepath: /usr/lib/ruby/site_ruby/1.8/hiera_puppet.rb
Line: 14
Detail: Could not find data item exim_tls_certificate in any Hiera data file and no default supplied
at /etc/puppet/environments/dev22/modules/exim/manifests/config.pp:88 on node rx1-mail-flex-van.dev-globalrelay.net
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Can hiera-eyaml be used to encrypt ssh private keys for use in hiera, or is it not possible?

I want to be able to keep ssh private keys in the git repo, but want them obfuscated.

Thanks,
Tom

Hello,

I have hiera with puppet configured to use yaml and eyaml backends. I have a hash configured in different data files, used with different backends. That is, keys with plain values are defined in common.yaml file and keys with encrypted values in the common.eyaml.

These are the files:

---
# common.eyaml

nsca::options:
  password: ENC[GPG,<encrypted key>]

---
# common.yaml

...
nsca::options:
  encryption_method: 2

# hiera.yaml
:backends:
  - eyaml
  - yaml
:yaml:
  :datadir: /etc/puppet/environments/%{::environment}/hieradata
:eyaml:
  :datadir: /etc/puppet/environments/%{::environment}/hieradata
  :extension: 'eyaml'
  :pkcs7_private_key: /etc/puppet/secure/keys/private_key.pkcs7.pem
  :pkcs7_public_key:  /etc/puppet/secure/keys/public_key.pkcs7.pem
  :gpg_gnupghome: '/etc/puppet/secure/gpg'
  :gpg_always_trust: true
:hierarchy:
  - "%{::fqdn}"
  - "%{::custom_location}"
  - common
:logger:  puppet
:merge_behaviour: deeper

In puppet (3.4) I'm using automating binding, but when I get options hash it only has passwordkey, but not encryption_method one. But when I test it with

# hiera -c ./hiera.yaml -h -d nsca::options
...
{"encryption_method"=>2, "password"=>"<plaintext password>"}

and it works.

Any idea?

When I try to eyaml edit a new file, eyaml dies with ENOENT. It seems reasonable that I should be able to create a new file and have things encrypted from the start.

The eyaml command is a bit of a mess - I can never remember which option to use for editing or encrypting? -e? -y? -i?

Anyway, I'd like to propose that we introduce sub commands, as per git and here is some thinking about how it should work (not how we should implement it).

We'd have four (five for the new recrypt function in #44) commands:

eyaml createkeys
eyaml encrypt
eyaml decrypt
eyaml edit
eyaml recrypt

Then there would be some global options and options for each command. For example, the existing --encrypt-method option (-n) would be global, but settings like --string which only make sense for encrypt and decrypt will only be available for those commands.

I think this will make the command much friendlier - at the moment I have to try a couple of times before I try the right options. I want to get it right first time. Also, the automatically generated short options are unpredictable as is seen in #30.

Interested to hear what you think. I don't think this is too hard (with the exception of merging options from plugins) and am happy to have a bash at it sometime soon.

We make lots of hiera_hash lookups which are hierarchically merged which in turn contain any string, array or hash. We expect :merge_behavior :deeper. When using other hiera backends, we need them to support this behaviour.

rooprob@850e978

This patch takes hiera 1.2.1 merge behaviour, and makes it optional for eyaml users. I also added configuring the extension from eyaml; we use "yaml".

RFC. Test cases pending.

I'm having decryption problems using hiera-eyaml-gpg, but the error that is being thrown is not helpful:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error NameError: undefined local variable or method `msg' for Hiera::Backend::Eyaml::Utils:Class at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

It appears to be coming from warn function in lib/hiera/backend/eyaml/utils.rb, line 143:

        def self.warn messageinfo
          message = self.structure_message messageinfo
          message = "[#{message[:from]}] !!! #{message[:msg]}"
          if self.hiera?
            Hiera.warn format_message msg
          else
            STDERR.puts message
          end
        end

If I replace msg with 'msg' (ie. a string), I get a different error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error NoMethodError: undefined method `format_message' for Hiera::Backend::Eyaml::Utils:Class at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

If I then replace format_message with 'format_message' (ie. a string, again), I get a more helpful error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error GPGME::Error::DecryptFailed: GPGME::Error::DecryptFailed at /etc/puppetlabs/puppet/environments/cxd_bld01/modules/cis/manifests/boot_settings.pp:24 on node cxdbld01app0101
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

I'm sure what the correct fix is - can I leave it with you?

Hi there,

I've just started to use .eyaml files and it seems that the "old" .yaml files are no longer being processed if/when there is a .eyaml file ?

Is it not possible to mix eyaml with normal yaml files ? Not every yaml config file will contain sensitive data.

Thanks!
Alex

(not exhibited by cucumber tests), arrays and hashes do not work properly in hiera/puppet run situations.

The reason for this is the eyaml_backend integration class, which propogates the key down to parse_answer, but does not repropogate it when recursively calling itself for array and hash situations

Hi,

Just curious why the secure keys are left in the /etc/puppet directory?

Puppet uses a location under /var/lib/puppet

I have no issues with it was just wondering if it was a conscious decision for some reason.

in the hiera.yaml

specifying
:datadir: /etc/puppet/environments/${environment}

works

specifying
:datadir: /etc/puppet/environments/${::environment}

does not work.

In the hierarchy bit:
:hierarchy:
- ${::environment}

works.

This is inconsistent for the file.

Have a good day.

-Shawn

Trying to encrypt a long value (such as an SSH private key) doesn't work at the moment with:

public_encrypt': data too large for key size (OpenSSL::PKey::RSAError)

I found this article which might help(?)

http://stackoverflow.com/questions/7143514/how-to-encrypt-a-large-file-in-openssl-using-public-key

If you do this it helpfully says:

A duplicate DEC(ID) was found so I don't know how to proceed. This is 
probably because you copy and pasted a value - if you do this please 
delete the ID in parentheses

This is a fail in the logic and should be fixed.

Not sure if this belongs to puppetlabs or yourself, but it would be really handy if deep merging was supported by eyaml.

Hello, I created rpms to install the hiera-eyaml gems (my work environment requires this) using fpm.

I have the puppetlabs hiera installed, and would prefer to stick with the puppetlabs version.

# rpm -qa |grep hiera
hiera-1.3.0-1.el6.noarch

which installs to:
/usr/lib/ruby/site_ruby/1.8/hiera

When I install the rubygems (rubygem-hiera-eyaml-2.0.1-1.noarch, rubygem-highline-1.6.21-1.noarch, rubygem-trollop-2.0.0-1.noarch) and try and use eyaml, I get:

# eyaml createkeys
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:779:in `report_activate_error': Could not find RubyGem hiera (>= 1.2.1) (Gem::LoadError)
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:214:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:249:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `each'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:1082:in `gem'
from /usr/bin/eyaml:18

I tried to symlink /usr/lib/ruby/site_ruby/1.8/hiera to /usr/lib/ruby/gems/1.8/gems/hiera-1.3.0 to no avail.

I can install fine doing a normal gem install, but the gem install overwrites the system hiera binary, and because the gem overwrites /usr/bin/hiera the next time puppetlabs updates their hiera rpm it's going to overwrite the gem binary and possibly cause problems.

Let me know if there is any other information you require.

Have a good day.

-Shawn

Had a few comments from users saying that when using the eyaml tool, its frustrating to always have to use command line args to specify alternative locations of keys, as the default is ./keys - meaning that they always have to cd to a directory before running eyaml command line.

They suggest a $HOME/.eyaml file which can provide sensible defaults for some variables. I think this is a good idea.

@gtmtech I was messing around with eyaml just now creating keys and writing cucumber tests etc, anyway I put the following in a debug line in the create_keys method of pkcs7.rb to see where keys were being created by default:

Pathname.pwd + ' : ' + public_key

then built and installed the gem and got this output

/home/tom/[stuff]/github/hiera-eyaml/ : /keys/public_key.pkcs7.pem

What is the default directory for keys meant to be, and also why would it default to a path inside my github repo after I've installed it as a gem?

Apologies if this is just the way gems work, I'm still new to this ruby stuffs

Do you think it would make sense to use /etc/hiera/keys or something as a default seeing as most of the time hiera-eyaml will be used via hiera?

BTW the cucumber tests are great, really useful for trying stuff out!

Following on from discussion in issue #3 it seems that there are benefits to using GPG over those provided by the current PKCS#7 implementation.

However, it should be implemented as a separate plugin so that hiera-eyaml doesn't depend on the ruby-gpgme bindings (because the native code needs gcc when installing the gem).

I'm using Puppet 3.5.0. Hiera 1.3.2. Eyaml 2.0.1. Oracle Linux 6.5.

I followed the documentation and everything works as expected, except the encrypted string doesn't get unencrypted during the puppet run.

I created a simple file type and a string variable in hiera. The problem is when I run "puppet agent -t" it just puts the actual encrypted string in place, not the unencrypted text.

In other words, this:

hostname.yaml
test: ENC[PR............VggBD652vwNiSvudBq6wuyHRpn]

eyaml edit hostname.yaml
test: DEC(1)::PKCS7[hello]!

file { '/tmp/test.txt':
ensure => present,
content => $test,
}

ends up with contents:
ENC[PR............VggBD652vwNiSvudBq6wuyHRpn]

and not:
hello

My hiera.yaml section:
:eyaml:
:datadir: /etc/puppet/hieradata
:extension: yaml
:pkcs7_private_key: /etc/puppet/secure/keys/private_key.pkcs7.pem
:pkcs7_public_key: /etc/puppet/secure/keys/public_key.pkcs7.pem

It would be great to get this working. Any thoughts?
Thanks,
Kent

eyaml -c should prompt to overwrite keys that already exist.

/etc/puppet# hiera secrets
/var/lib/gems/1.9.1/gems/hiera-eyaml-2.0.1/lib/hiera/backend/eyaml_backend.rb:19:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:172:in `new'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:172:in `block in lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:170:in `each'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera/backend.rb:170:in `lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/lib/hiera.rb:60:in `lookup'
    from /var/lib/gems/1.9.1/gems/hiera-1.3.2/bin/hiera:221:in `<top (required)>'
    from /usr/local/bin/hiera:19:in `load'
    from /usr/local/bin/hiera:19:in `<main>'

That's the error I receive when trying to simply list a hash. Let me know if you need anything else!

With the new eyaml parser from I'm seeing the cipher text indented each time on the blocks you don't update

eyaml -i test_input.yaml

update a random key just to trigger a file diff on save, and diff, and notice the blocks are now more indented.

I can see eyaml/parser/encrypted_tokens.rb to_encrypted() adds this indentation, and I'm considering suggesting just dropping it. I'm still unwinding these changes from my 1.3.4 fix to find a better solution.

ciphertext = @cipher.gsub(/\n/, "\n" + @indentation)

+++ b/features/sandbox/test_input.yaml
@@ -1,33 +1,35 @@
 simple_string: how do you do
 encrypted_string: ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQEBBQAEggEAgld+r
-encrypted_default_encryption_string: ENC[MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhvcNAQEB
+encrypted_default_encryption_string: ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZIhv

 simple_block: >
     once upon a time
     in a galaxy far far
     away
+    the original three
+    are the best

 encrypted_block: >
     ENC[PKCS7,MIIBiQYJKoZIhvcNAQcDoIIBejCCAXYCAQAxggEhMIIBHQIBADAFMAACAQAw
-    DQYJKoZIhvcNAQEBBQAEggEAYzeWn3MBLhOs4hokxMCWcDd9VuwCylQRUQ0w
-    KwCObeORw8PJkCDvi5ZIA2YkrvYTT6u3/7KfAiHd0Rg1WLb9et0Mg/Fd3DFF
-    7qhqOGHoQt3+4eKzlcikeR0/Lqrq2vTpqZ2Sw1CZ7Dn+Z4ll95p7lp97rb2J
-    kYTVroLYGWEcsS3JZLL4/l3z0bJbXNKKqJ1aHCAFq+wmWXeb6cDvvyHFg2N/
-    vGPFEQjP7AbWhxHxXDbYIGcU073u5NtE40JXL8SH82iHxqRF8s9g6Dh5cmjg
-    AY2pkBD9e6N78NNx+PAJswsFAV4DOCbXdf2BisyYbM3na35MVfyb6ggDegrE
-    ebOxxDBMBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCWeGlYS5cQoX78L6LK
-    /mczgCD/pI7usp1XPebnN8CngxHXuUjj5S+6IUpOW6l2JgUeWw==]
+            DQYJKoZIhvcNAQEBBQAEggEAYzeWn3MBLhOs4hokxMCWcDd9VuwCylQRUQ0w
+            KwCObeORw8PJkCDvi5ZIA2YkrvYTT6u3/7KfAiHd0Rg1WLb9et0Mg/Fd3DFF
+            7qhqOGHoQt3+4eKzlcikeR0/Lqrq2vTpqZ2Sw1CZ7Dn+Z4ll95p7lp97rb2J

^^^^^^^^^ indent grows each save

./keys is not a sensible default private key path.

It would be good to be able to set your own default key path rather than running --pkcs7-private-key or creating a bash alias to do so.

Perhaps eyaml edit could read from ~/.eyaml/config or similar?

It seems that JRuby is not happy with the X509 Certificate (public key) generated by the eyaml command. Therefore, you cannot use hiera-eyaml with JRuby.

eyaml wants the cert to have an "issuer" (see below):

$ bin/eyaml edit test.eyaml
[hiera-eyaml-core] !!! Empty issuer DN not allowed in X509Certificates
[hiera-eyaml-core] ["org/jruby/ext/openssl/X509Cert.java:161:in initialize'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:48:indecrypt'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:15:in encrypted_value'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:80:increate_enc_token'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/encrypted_tokens.rb:110:in create_token'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:71:inparse_scanner'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:74:in parse_scanner'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/parser/parser.rb:36:inparse'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/subcommands/edit.rb:36:in execute'", "/Users/clarence/.rbenv/versions/jruby-1.7.4/lib/ruby/gems/shared/gems/hiera-eyaml-2.0.0/lib/hiera/backend/eyaml/CLI.rb:45:inexecute'", "bin/eyaml:13:in `(root)'"]

Getting the following after upgrading to 1.3.1 and trying to edit a file using eyaml -i.

/var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/utils.rb:42:in delete': can't convert File into String (TypeError) from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/utils.rb:42:insecure_file_delete'
from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/actions/edit_action.rb:25:in execute' from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/lib/hiera/backend/eyaml/CLI.rb:100:inexecute'
from /var/lib/gems/1.8/gems/hiera-eyaml-1.3.1/bin/eyaml:13
from /usr/local/bin/eyaml:19:in `load'
from /usr/local/bin/eyaml:19

This is pretty weird. I'm assuming this is due to hash order randomization?

[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Enter password: ***
    ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAw
    DQYJKoZIhvcNAQEBBQAEggEAsGrtWLcc8L+ShTE22jSMLXwcmdKRkQ5Lu9Je
    Jr1596/DMK7cmIGsGokeY15bmAO5GXG/PcCyliEZi0hmR5woBBbuefKa67NN
    peD0fFuv7aQmXHeWXRUkPfPYm7OgJthZYGmRsVUckKpsE47Sk5ZbMbPqBFQ0
    3IDxVD93v8SQ7FHb69s6erpxWVv9hVXf+/BFYMVmI+yZeXf/KMK+cxQvlESp
    n/RhdxRvXN0s5v8cVU7yIFI80l22atvs3+DDK41dHL8N2md8O20xKuDkHOA3
    /2n92XIiGoQ7Rmk7wT/YGgCLkBxFYo6rldZVQOEEbWkiDpLEgMwYF8t0DXN6
    mbXhszA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDQD8SGwxmo6luXO9eu
    XadTgBCN5JeHXP+t6YhS4dgm370Z]
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Error: unknown argument '-r'.
Try --help for help.
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Error: unknown argument '-r'.
Try --help for help.
[[email protected] ~]#  eyaml -e -r /etc/hiera/keys/private_key.pem -k /etc/hiera/keys/public_key.pem  -o block -p  foo
Enter password: ***
    ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAw
    DQYJKoZIhvcNAQEBBQAEggEAUUPbMbyLny5U/GHvJM+PjUntMW9ov42yaVc4
    YA9KEMuyGPKuBX3hTPueCdvOsHBL2SsfZzi3Qta0d6alJH2Llc+7VQ53R/Sf
    ibUsr57Xwne43cmLjjYSkIHrySF7nOuBx0xTtWvtxwLJIGG3my/HnQuN59sn
    CikRPPeVX1NYLFgjhqGC4/ByVNeSQ6sXoSUDppLDvTavy17um9JrfymvG0+a
    +lFEstgXirvsVzyNNT/EopjRTXZzqTaMEXYChkV4RcMHlq6VjH///5NgL0du
    x/STy1hH04XuYroSCTYbrAPoSAkuNwshLvGsqg2SMPn2z0h4lePwBC0qFb2Z
    Up/HYjA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBB3/1k0O75f4hcNLR3y
    0Bi9gBCYsiK4AfekoBmj0rFicYZF]

(version 1.3.4)

with hiera-eyaml 2.0.2 on CentOS 6.5 latest updates.

create simple eyaml with:

eyaml encrypt -l 'test_password' -s 'password1234' >> common.eyaml

cat common.eyaml
test_password: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTWD1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXReqTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mEZ2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVASalvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6DtjogBAna/xVM/tqXymnf4XvAcPh]

OR

test_password: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTW
D1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXRe
qTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//
lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mE
Z2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVA
Salvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k
+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6
DtjogBAna/xVM/tqXymnf4XvAcPh]

Edit the eyaml and delete the first value and add a yaml header thingy:

eyaml edit common.eyaml

cat common.eyaml

test_password: >
ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw
DQYJKoZIhvcNAQEBBQAEggEAV+kmvArZ4Sf0NMcOUvEuxaKnUAY/TNIo4KTW
D1obN7KIEPNCDsBryTdFuj5z4+7CTm0ONIhykjB22BDv/XV0TelL4U+ZtXRe
qTgBtbGM3+KDh/t6t/lbqKNczKLLYmSvFs2jhgy4Ghh1xj/1Mk+i7PP3yq//
lByUsFqmeG6EFrg92jcH47hByHMS04w70NO26jTmH+VqzLU3oql+9RyFl2mE
Z2mgTJi3jH47QYoxfaVLYH3kBuHTMYmGSYQzL5tG16oGKpWaiuH5VkfyZnVA
Salvlb5xO4c/X1HdRhRg3QDuTSjfzjFK0vOsINb+esNAZmWuA9fijlbRvy/k
+T0WwDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBugUfpDY3QIj+qQ5y6
DtjogBAna/xVM/tqXymnf4XvAcPh]

Edit the eyaml again and add a second value:

(vim window looks like this:

test_password: >
DEC(1)::PKCS7[password1234]!
prod_password: >
DEC(2)::PKCS7[4321drowssap]!

Save the file and get this error:

eyaml edit common.eyaml
[hiera-eyaml-core] Loaded config from /root/.eyaml/config.yaml
[hiera-eyaml-core] !!! undefined method plain_text' for #<Hiera::Backend::Eyaml::Parser::NonMatchToken:0x7f16ab7dedf8> [hiera-eyaml-core] ["/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:70:inexecute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:67:in map'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/subcommands/edit.rb:67:inexecute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/lib/hiera/backend/eyaml/CLI.rb:45:in execute'", "/usr/lib/ruby/gems/1.8/gems/hiera-eyaml-2.0.2/bin/eyaml:13", "/usr/bin/eyaml:19:inload'", "/usr/bin/eyaml:19"]

(common.eyaml still looks the same as the previous cat output, nothing was saved)

eyaml -c fails on 32-bit linux:

In the file: hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72
This is the line that causes the problem:

cert.not_after = Time.now + 50 * 365 * 24 * 60 * 60

After some Googling, it seems that 32-bit can only hold a Time up to the year 2038 (see: https://groups.google.com/forum/#!topic/comp.lang.ruby/VcZfhxUNXBU).

For example, if I change line 72 to:

cert.not_after = Time.now + 24 * 365 * 24 * 60 * 60

Then eyaml -c works fine.

Perhaps the not_after date should be an option rather than hard coded?

My ruby version is: ruby 1.9.3p448 (2013-06-27 revision 41675) [i686-linux]

Sample error output:

Are you sure you want to overwrite "./keys/private_key.pkcs7.pem"? (y/N): y
/opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72:in not_after=': bignum too big to convert intolong' (RangeError)
from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/encryptors/pkcs7.rb:72:in create_keys' from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/actions/createkeys_action.rb:14:inexecute'
from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/lib/hiera/backend/eyaml/CLI.rb:101:in execute' from /opt/puppet/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.3.4/bin/eyaml:13:in<top (required)>'
from /opt/puppet/bin/eyaml:23:in load' from /opt/puppet/bin/eyaml:23:in

Hi @gtmtech and @sihil, I created this to track general project stuff that isn't specific to a particular issue.

First notice is that I've started adding lightweight tags to the commits that correspond to releases, as commits that update the version number aren't necessarily the last commit to be included in the build. Basically I just did git tag v1.3.5 which means we can now use git tag to get a list of commits corresponding to versions and git show v1.3.5 to get the commit info for that version.

It might be useful for something, mainly I just added it to play around, but we should continue to do it on future versions.

It should have a better error message.

# eyaml -c

/usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:19:in `mkdir': No such file or directory - /etc/hiera/keys (Errno::ENOENT)
        from /usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:19:in `ensure_key_dir_exists'
        from /usr/local/lib/ruby/gems/1.9.1/gems/hiera-eyaml-1.1.4/bin/eyaml:133:in `<top (required)>'
        from /usr/local/bin/eyaml:23:in `load'
        from /usr/local/bin/eyaml:23:in `<main>'

Hi,

since the newest update I've got problems with updating my existing environments.
Before only private key was required for decryption, and now since it need public as well it doesn't accept it in the format I've created them (following instructions here)
throwing "nested asn1 error"

in eyaml_backend.rb

public_key_pem = File.read( public_key_path )
public_key = OpenSSL::X509::Certificate.new( public_key_pem )

I think it should be

public_key = OpenSSL::PKey::RSA.new( public_key )

to be compatible with existing deployments.
Is there any specific reason this has been changed?

Cheers,
Piotr