Show HN: Greybox – symmetric configuration file encryption | Hacker News Reader

Show HN: Greybox – symmetric configuration file encryption

github.com

asymmetric

Can you explain further what workflow made you implement this? Why is this asymmetric in the first place? Is there an advantage over having a checked-in "config.dist.yaml", which is copied on every installation as "config.yaml"?
From what I can see, instead of having one password (e.g. the production database password), we now have two: the password and a private key to decrypt it.
Sorry if this sounds so negative, but in my work environment, managing this crypto infrastructure would lead to more complexity and less security.

Are you saying you check in your database password into the repo? A common suggestion is to have an empty file with placeholders for the actual values (config.sample.json or something), but the actual values have to be somewhere, right? And that file that contains the actual values is typically outside of source control so it is hard to keep up-to-date.

Yeah, that's what we do. We never check passwords into VCS. Sorry if my original post sounded differently.
My question was the other way around. Why should I start checking in my (in this case with your library) encrypted passwords into VCS? When is that ever a good idea?

I looked around for best practices regarding how to manage configuration around credentials like secrets, tokens, etc. John Resig talks about both approaches - the one you mentioned, and my approach [1].
The major downfall of the approach is that configuration files, regardless of whether they contain secrets or not, tend to be exactly the kind of thing you want in source control. Maybe not the same repository, but having the files in source control has nice properties like keeping it up to date across servers. There are even tools [2] to validate a configuration file that you end up creating, because the real file (in Resig's example, settings.json) is usually in gitignore and outside of source control. Why not keep it in source control? Heroku suggests [4] using their proprietary configuration management system. This is a simple open source way to do so with no configuration management system required and almost no overhead.
I don't like that approach because it's easy to get the settings sample JSON out of date, and moreover I don't like the fact that the settings files themselves aren't under source control. Why not?
This [3] stack overflow post goes over a few approaches and I agree - "Public Key Cryptography is the most flexible answer."
[1] http://ejohn.org/blog/keeping-passwords-in-source-control/ [2] https://github.com/jkassemi/conf_conf [3] http://programmers.stackexchange.com/a/163792 [4] https://devcenter.heroku.com/articles/config-vars

Reply on news.ycombinator.com