[ganonm]

It's so easy to avoid having them in VCS though. Any secrets can be loaded from a configuration file placed in ~. Populated configs can be selectively distributed so you can e.g. only place the production config file (with the prod server AWS keys for example) on the CI server. Everyone else just gets a config file with non-prod secrets. This can help avoid a lot of mishaps.

[danenania]

The problem with config files outside of vcs is keeping them in sync, which leads to bugs, insecure sharing methods, and constant interruptions as developers need to bug each other to get the latest values.

Shameless plug, but check out EnvKey[1].

With 10-15 minutes of effort, it gets secrets out of git, out of email, out of Slack, etc. It manages encryption keys safely behind the scenes, protects development secrets just as strongly as production, keeps devs and servers automatically in sync, and greatly simplifies access control and key rotation.

It's not the only solution out there, but it's by far the easiest to setup and work with. In any case, use something that truly solves the problem! Don't settle for half-measures that end up spraying secrets all over third party accounts. This stuff is serious--even when it comes to so-called development secrets, the line is fuzzy.

1 - https://www.envkey.com

[techdragon]

Shameless or not, this is the first time I’ve seen a hazmat[1] handler I understood by the end of the first page and the price is low enough I’m just signing up now to use it for all my personal projects. Thank you for sharing it here.

1 - encryption keys and secrets are “hazardous material”, shortened to just “hazmat”. While necessary and arguably crucial in our work, they deserve the same care and respect a chemist would have for a beaker full of particularly dangerous chemicals.

[danenania]

Glad to hear it! Feel free to reach out with any feedback/questions/issues: dane [at] envkey.com