[Rygu]

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.

[Xylakant]

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.