I'm not sure how helpful that would be.

It seems to me, if you're going to require the decryption keys to be present on any machine that wants to boot the application, even in development or test, you might as well just git-ignore secrets.yml, and distribute it via whatever side-channel you're using to widely share the key.

In my mind, the value of the encryption is that you can keep the secrets with the application while only needing to distribute the keys to the subset of deployments that actually need the "secret secrets".

to use it as desired

Can you elaborate on your intended use case, perhaps? If every clone of the repository needs the keys in order to be useful, which dangers/attacks are being thwarted by the encryption?

Currently I have an application where I'm authenticating a user with Facebook. Every environment has it's own Facebook App Secret (development / staging / production) since OAuth redirect URLs must match the specific servers.

I thought that secrets.yml.enc would be the best place for this.

Sure I could add all of this to secrets.yml and put this into .gitignore. But that would mean that I need to distribute Facebook App Secrets to my team for all environments or send the secrets.yml directly.

With the new mechanism I just need to distribute the key.

Alternatively we could adapt the documentation to state:

say "Add this to your config/environments/(development|production).rb:"
say "config.read_encrypted_secrets = true"

But please tell me if I got the whole thing wrong :-)

But that would mean that I need to distribute Facebook App Secrets to my team for all environments or send the secrets.yml directly.

With the new mechanism I just need to distribute the key.

Right.. but either way, you're distributing a single file / string. What makes this string better than the other one?

Personally, I'd put the production and staging keys in secrets.yml.enc, and the development key in secrets.yml. That way no-one's laptop contains the production key. (For this purpose, I'm counting "contains an encrypted file holding X with a decryption key next to it" as "contains X".)

If I can choose between sharing string or a yml file I'd prefer the string - but I guess I'm nit-picking here so I'll elaborate the full process: I was trying out the new mechanism (out of curiosity) and in development the keys didn't show up until I've added the line from above to the development.rb.

What do you think about adopting the documentation to let the user decide in which environment he wants to use the mechanism? Or do you even discourage people to use secrets.yml.enc in development?

Or do you even discourage people to use secrets.yml.enc in development?

We're only going to recommend it for production secrets, yes. Feel free to try your hand at a doc PR that elaborates on the read_encrypted_secrets config (just explaining that it's there, but it shouldn't recommend adding it in dev, test).

Ok cool. Could you point me to the source of the docs and I'll write up my findings.

@sebastiandeutsch took a stab at it in b16dcc8 since we're (hopefully) close to another release. Thanks!

Sweet :-)