

Show HN: Greybox – symmetric configuration file encryption - greenleafjacob
https://github.com/jacobgreenleaf/greybox

======
greenleafjacob
asymmetric _

~~~
xrstf
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.

~~~
greenleafjacob
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.

~~~
xrstf
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?

~~~
greenleafjacob
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/](http://ejohn.org/blog/keeping-passwords-in-source-control/) [2]
[https://github.com/jkassemi/conf_conf](https://github.com/jkassemi/conf_conf)
[3]
[http://programmers.stackexchange.com/a/163792](http://programmers.stackexchange.com/a/163792)
[4] [https://devcenter.heroku.com/articles/config-
vars](https://devcenter.heroku.com/articles/config-vars)

