Later I'd like to inline just the parts of Sekrets we need, since it seems to a lot more than we require as well as pull in a number of dependencies (nothing wrong with that, but it's best Rails keeps slim).

@ahoward how would you feel about that? We'd inline the parts we're using into it's own private namespace and give you credit with: # Adapted from Ara T. Howard's Sekrets gem..

Also: as a heads up, it seems Sekrets isn't distributed with a license :)

Dang, I've got trouble getting https://github.com/kaspth/rails/blob/226db6a15bc5ce5aca1854d7d2a00ab221795f86/railties/lib/rails/application.rb#L388 to recognize config/secrets.yml.enc. config.paths don't seem to be too willing to cooperate, I imagine I need to add a glob to it somehow.

I don't understand why config/secrets.yml.enc would be gitignored? Isn't the whole point to check the encrypted secrets into the repo, but keeping the key out of the repo? So think we should remove that file from gitignore, leaving only the key file there.

I'm also hesitant to generating this key upfront. It's pretty easy for someone then starting a new project to use this feature but forget to do something about the key file, like commit it to 1Password. If they forget that, then change computers, the encrypted data is inaccessible. IMO, better that there's a kick-off for the first time you use encrypted secrets that explains that we're generating the key, putting it there, and you should store it securely somewhere outside of the repo.

Otherwise I'm liking the simplicity of this a lot!

@jeremy Could you review as well?

So I'd add bin/rails secrets:new or something like that for the initialization. Could also just combine the two steps and have bin/rails secrets, which would initialize if secrets.yml.enc is missing, and otherwise go to the edit session.

I don't understand why config/secrets.yml.enc would be gitignored?

It shouldn't! That was me being a dummy, thanks 👍

We could potentially try to remove the need for the config/secrets.yml.enc file entirely and just enable encryption on string keys in config/secrets.yml.

So when reading config/secrets.yml we traverse it and any string values starting with a signature ala this we decrypt. Then on write we just encrypt every string value (and prefix the signature).

Will be nice to add this to CHANGELOG also.

Is production.secret_key_base value relevant if new encrypted secrets is enabled? Is it the same or diff to RAILS_MASTER_KEY?

If we run rake secrets:setup can we replace/delete config/secrets.yml to avoid ppl using it?

Wrote a little getting-started/investigation blog post http://www.starkandwayne.com/blog/rails-5-1-applications-can-be-a-lot-more-secretive-on-cloud-foundry-and-heroku/

Sorry to sealion in here but someone referred me to this PR from Twitter and it seems like you've set things up to use only a single key. This will likely make key rotations in production environments either very tricky or impossible. I would ask if you have the time before the feature goes live to make it possible to keep multiple copies of encrypted settings such that new code and new keys don't have to be updated in perfect lockstep.

Also I would recommend warning people about the dangers of storing the key in an environment variable. It does make life easier for PaaS users but caveat emptor. Tools like Airbrake and Sentry will need to be updated ASAP to not automatically log the environment variable (and configuration for each should be used in the interim). Also storing a key in an environment variable means it is passed to all subprocesses of Rails, which can be an issue for things like ImageMagick for thumbnail generation.

Key rotation would be amazing. We don't have that for secret_key_base now do we?

Also rollbar and sentry AFAIK use env var whitelisting so they won't need to be updated. If airbrake does something different then it has bigger problems than this PR.

Probably the best that can be done for rotation for the moment is to rework the filename structure so rather than a single secrets.yml.enc make room for multiple files. Once authenticated encryption of one type or another gets added, the system can then be improved to try all of them in order until one works. But having the folder structure in place now will make the transition easier even if the rotation system is added after initial release.

@coderanger - one of the main uses we've found for app specific secrets is keeping things like credit cards, private certs, etc, stored in a repo. aka, not just *.yml based config. this led to the development of an 'Sekrets.load(path)' api. from there it is trivial to support Sekrets.load("#{ Rails.env }.yml") etc. so totally agree.

@kaspth @dhh

Once I have enabled encrypted secrets, I always need to open the editor to add a new key:

$ rails secrets:edit
[… add a new key in the editor, save and exit …]
# New secrets encrypted and saved.

How do you feel about a new feature to programmatically add encrypted secrets without needing an editor?

$ rails secrets:add API_KEY=123
# New secret API_KEY encrypted and saved.

The concept is very similar to the way in which Travis encrypts environment variables.

Just a small point, but could somebody add a few lines to the USAGE file (and, preferably, the Rails 5.1 release notes as that's what comes up when you search the web) detailing how you actually get the secrets OUT again?

The release notes say

Secrets will be decrypted in production, using a key stored either in the RAILS_MASTER_KEY environment variable, or in a key file.

but they forget to mention where they're decrypted TO, and I suspect most people wanting to use this feature won't be too keen on having to spelunk through the 17 changed files on this PR…

Please do investigate, then!

It's an encrypted yaml file. Hence it's also yaml when it's decrypted, not just for "editing purposes".

I've just updated to Rails 5.1, moved all my keys to config/secrets.key.enc, updated .profile exporting RAILS_MASTER_KEY and then my deployment process started to fail because capistrano didn't have access to this variable.. I fixed it by adding set :default_env, { RAILS_MASTER_KEY: IO.read('config/secrets.yml.key') } to my config/deploy.rb file.. maybe someone finds this useful.