Encouraging the committing of .env is a violation of twelve-factor about dotenv

[wyaeld]

I would agree.

While I'm not using dotenv itself, I follow a similar practice, of committing all sensitive configuration files as someconfig.yml.example, showing all of the variables, but usually without a value.

This is followed by a comment to copy/rename, and get the most recent values from campfire, another dev, or some other secure location used by the team.

Otherwise a practice like this is essentially useless on an app in a public repo.

[allaire]

What about having .env as the development config values, and also have .env.production and .env.staging that are added to .gitignore?

[brianburridge]

I don't think committing a .env that has development only values in it is what the 12f doc is referring to. The point is to not check in sensitive data, but a .env file that is only for development is not a risk to your production running app. Certainly, you should never check in passwords, secrets, etc for production. If for any reason you connect to production services in development, then of course, you shouldn't check those in either.

[binaryphile]

That may be entirely correct and I'm just not getting the usage pattern. It seems to me that what they are trying to prevent is the possibility that the contents of a single file, not in the ignore, should not possibly contain sensitive production data.

For example, if .env were automatically not used by the gem so long as the app is running in production, that would not be contrary to their point. If instead the gem only used .env.production or somesuch when run in production, and that file were in the ignores, that would ensure that .env is only ever used for non-sensitive data.

What they are trying to avoid is this common scenario: database.yml comes with some defaults for development. The developer doesn't add it to the gitignore and checks it in, either deliberately or not. It works for everyone in development and things are happy. Then the file makes it to deployment, where it is edited to insert sensitive production values. Since it is not in gitignore, eventually someone commits on the production machine and pushes to the repository. Now sensitive data has been leaked to everyone.

For this reason, any file which is used for production data goes in the ignores. Since there's overlap with development here, a copy of the file is included with sensible dev defaults, but is put under another name since the original filename is ignored. The developer only has to copy the default file to the name expected by the system.

There's more than one way to skin that cat, definitely, I've only spelled out the way I've seen it done. However, the point is that a file which may reasonably contain production, sensitive data, should always be ignored.

The best thing is to have a hard separation between filenames used for dev and production. Barring that, there should be no way for the filename which will in have production values in the production environment to be accidentally checked into git. That means it has to be ignored.

From your readme, your model fails to maintain this separation. There is only a single file used by either dev or production, .env. This file is encouraged to be kept in git. Thus on the production server, it will contain production values and only be a single git commit away from becoming part of the change history. That's exactly point of what I quoted from the 12f docs, and you only have to have made that mistake once to see why it's discouraged.

[bkeepers]

dotenv was originally intended to be development-only. People started using it in production and I got lazy and allowed features to be added that encouraged that. With #71, I'd like to fix that, and break production behavior into a separate gem (and probably discourage use of it in place of better alternatives).

[binaryphile]

Interesting. Perhaps that should be noted in the readme, as that makes it more clear.

That's also unfortunate...dotenv seems to be the best way to ensure security in the production environment. Environment variables are an insecure way to pass sensitive information in some environments, but 12f rightly notes that it's also a risk to put that information in files under/near version control. Your gem gives the best of both worlds if you just put .env in the ignore file.

Thanks for the software!

[bkeepers]

We're still thinking through the appropriate solution. I'll update the README when we figure it out.

[allaire]

IMO dotenv is a perfect product for production, it's the main value I see from it :) I think we just need to figure out the best way to do it.

[wyaeld]

I think its a matter of risk.

A modern web app is typically using several public APIs, and these days that requires keys, secrets and other info.
While the above comments are correct in that storing development values doesn't strictly create a risk to a production environment, its certainly inconvenient to the development team if even the development accounts on some services get compromised because values leak, and when people are rushing, they don't always have seperate accounts for different environments.

I do agree that Rails encourages some of this, although every mature rails practice I know does some variation of the following:

rails new app
echo "config/database.yml" > .gitignore
cp config/database.yml config/database.yml.example
git add .

I think dotenv has useful features for loading into any environment, but it would be better if we encouraged a better practice of how people handle the file. Private github wikis & secret gists also work well.

Most of us should have the freedom - if desired - for using tech like this, building an app in the open, and still knowing that all private config is safe.

[dalizard]

If the .env file is in not in .gitignore, how would you keep its content different in different environments? Appending the environment to the filename, and keeping .env for development is quite reasonable.

[allaire]

@dalizard What I do is I have .env.production in gitignore, and I have all my development stuff (same keys as the .env.production file) in .env, which is not gitignored.

Before deploying with Capistrano, I simply upload the .env.production file and rename it to .env so its 100% compatible with foreman.

Here's my cap task that does the upload trick :

desc 'Upload env file'
task :upload do |t|
  on roles(:all) do
    dotenv = ".env.#{fetch(:stage)}"
    upload!(dotenv, "#{shared_path}/.env")
  end
end
before 'deploy:check:linked_files', 'upload'

[bkeepers]

In 16802b7 I clarified my stance on committing the .env file, and in 2.0 (#160), a .env.local file will be also loaded.

I would be happy to entertain an PR with changes to the recommendation in the README, but this is how I handle it on the applications that I maintain.

[chrisnicola]

One problem I'm running into with this is there is a completely different philosophy here vs. NPM dotenv and dotenv safe projects. I think the dotenv-safe project has the right idea here.

Commit an example file, it could have default dev values in it and blank values to be filled in, and then locally you can copy it over to .env. It will then report an error for any missing values that are in .env.example to the user so they know exactly why things aren't working.

The reason I bring this up is becoming more and more common to be dealing with both Ruby and NPM on the same project these days.