
Deploying app ENV variables with Rbenv, Passenger and Capistrano - bjansn
http://blog.intercityup.com/deploying-app-env-variables-with-rbenv-passenger-and-capistrano/
======
tterrace
"Put the secret into your shared/.rbenv-vars file"... and then say goodbye to
them! [http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2014-0...](http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2014-0130) . I don't think keeping your secrets in a
file accessible to the web server is a good idea because of LFI vulns like
this.

Some other ideas that I've heard that may be better: store the secrets on a
separate "offline" server that only the web server can talk to. Or have the
file readable only by root, run a bootstrap script as root that would read the
file, drop root privs, and then start the webserver.

~~~
msikkes
Ok. What about your database password? I think that your application will
always have files that it should read for configuration files or other
passwords...

------
hackerboos
I'm going to go ahead and say that most people don't need rvm/rbenv/chruby etc
in production.

Ask yourself if you really need multiple versions of ruby in production
because if not you can save yourself the headache of setting it up.

~~~
msikkes
We use it because we'd like to run multiple apps on one server. This way we
can do that. With the added benefit of the .rbenv-vars to specify ENV.

