Hacker News Reader

Comment by Xylakant | Hacker News Reader

Because it's not a problem for private applications. You actually do want the key in your VCS in most cases since it should be stable across deploys. Rails will log out every user and throw an error for each active session when the key changes because it suspects that the session has been tampered with.

The handling for OS applications is a little more difficult and I must admit that I know a couple of mediocre and no good solution to it.

View on HN

I have to disagree. An application connected to a network is never "private" unless you configured a strict firewall and are sure that other running services don't contain exploits. Besides, if an employee leaves the company, this "private" app is now known to an outsider.

Also, just because something needs to be "stable across deploys" doesn't mean it needs to be in VCS. Are your application's third party passwords and API keys all stored in its version history? We picked a solution where the deployment tool configures the sensitive pieces of the application.

Private was meant as "the source is kept private". In this case it's less of a problem since only people with access to the source get to see the source. In any mid-size team those probably have access to the servers anyways, so they have access to the secret in any case, so they're implicitly trusted. You're certainly right that there are other ways to store the secret and if you read my posts in this thread you'll see that I'm aware of that, however, keeping the secret in the VCS is a simple solution that works without any further magic. If your requirements dictate that you can't do that, chance it, but that doesn't mean it's not a working solution for many other people. And that's the reason things are as they currently are and I don't expect them to change soon.

To answer your second question: depending on the case, I store 3rd party passwords and API-keys in the repo. If an employee leaves the company I'll have to change those anyways since he probably had access if he had access to the project at all.

In this app's case the setup.rb is an ideal candidate for generating a new secret_token (and raising an exception on startup until you've generated a token).

I actually went through the setup.rb and was surprised they don't do it. Rails itself will raise the exception if the initializer does not exist IIRC, so just removing the file and .gitignoring it would do.

.gitignoring will hurt anybody deploying via git (e.g. heroku) in the absence of some ENV magic. It'd be fine to have the regenerated file checked into each user's repo as long as they have the good sense not to push that repo up to a public fork on github.

There is talk about more general solutions here:

https://groups.google.com/d/msg/rubyonrails-core/N2EFnf6X_i4...

Neither of the solutions is actually beautiful, they all require some sort of deployment magic - env variables set, cap symlinking files or similar. What works for me probably doesn't work for you.

Btw: you can check the regenerated file into the repo, adding it to .gitignore just prevents you from accidentally adding it:

  Last login: Tue Jan 15 17:07:14 on ttys005
  Voice-of-Evening:~ fgilcher$ cd /tmp
  Voice-of-Evening:tmp fgilcher$ git init test
  Initialized empty Git repository in /private/tmp/test/.git/
  Voice-of-Evening:tmp fgilcher$ cd test/
  Voice-of-Evening:test fgilcher$ echo "README" >> .gitignore
  Voice-of-Evening:test fgilcher$ touch README
  Voice-of-Evening:test fgilcher$ git status
  # On branch master
  #
  # Initial commit
  #
  # Untracked files:
  #   (use "git add <file>..." to include in what will be committed)
  #
  #	.gitignore
  nothing added to commit but untracked files present (use "git add" to track)
  Voice-of-Evening:test fgilcher$ git add -f README
  Voice-of-Evening:test fgilcher$ git status
  # On branch master
  #
  # Initial commit
  #
  # Changes to be committed:
  #   (use "git rm --cached <file>..." to unstage)
  #
  #	new file:   README
  #
  # Untracked files:
  #   (use "git add <file>..." to include in what will be committed)
  #
  #	.gitignore
  Voice-of-Evening:test fgilcher$

That doesn't stop you from accidentally pushing it to GitHub though.

No, quite to the contrary: Once you do this, you'll push it in the next commit. But in the case of an OS app you'd probably want to create a private repo for the app since all your configuration would be public otherwise. If you deploy to heroku, you'll have at least one private git repo on heroku.

Reply on news.ycombinator.com