Blackbox: Safely store secrets in Git
github.com
github.com
With transcrypt, I do the encryption/decryption transparently once a repository has been configured by utilizing Git's clean/smudge filters, but it uses OpenSSL out of the box rather than GPG. A different workflow, and there are certainly pros and cons to both ways.
I think it probably works better integrated into the deployment system. The developer can still write {{ DBPASSWORD }} wherever they need and not have to worry that they don't know what the password on production or staging is.
I know some folks who use Pass and recommend it highly, but it seems focused on the personal use case like what you're doing.
I do still need to set up Pass myself, and was thinking about making an Alfred workflow to let me quickly access credentials. Does such a thing already exist? (searching for "pass" is not exactly effective :))
pass init [-p sub-folder] user1@example.com user2@example.com
Perhaps it should keep a signed copy of the last version of pubring and show a some kind of diff between the verified previous version and the current version before going ahead.
By encrypting only the password entries, version control systems can still track plain text configuration changes without showing secrets.
Does anyone know if something like Jaeger is around but written in Python?
Ironically Blackbox was originally for a Puppet repo that used Mercurial and only supported Git as a skunkswork project. Now it is devoid of any Puppet dependencies and is mostly used for Git, but the Mercurial support is solid. In fact, you could easily extend it to support other systems. CVS support, anyone?
For environment-based configuration values and multi-member teams, I wrote conf_conf [1].
I create/view/edit files and then I push the directory containing them to some git remote.
https://gist.github.com/anonymous/df1ba398dd4e4748c6cd
Usage commands at the bottom.
Really neat thing was that you could inline encrypt just the secretes making the rest of the Puppet module viewable and comprehensible.
This was originally written for Puppet files. The Puppet Master needs to have a separate key that permits it to decrypt all the files.
To encode: openssl aes-256-cbc -a -salt -in secret.zip -out secret.zip.enc
To decode: openssl aes-256-cbc -d -a -in secret.zip.enc -out secret2.zip
this solves the large team problem, too- it fetches membership data and ssh pubkeys from ldap. great if you have it, but only exists in large organizations.
this of course doesn't do the gitwork for you, but it does avoid creation of another set of keys to be mismanaged.
So there's still the part about compromising the encryption software. Well, GPG is not proprietary so that's a lot harder.
As far as somehow brute forcing the cyphertext, I guess that may be possible, though they don't give clear details about that here. That being the case, they still don't say anything about GPG. Perhaps the biggest argument of all is that Edward Snowden himself uses it, knowing everything he knows.
But the ITAR directory on the NAS was never rsynced. Instead, they drove the files out there every week using a flash drive.
Seemed like a crazy policy to me, but after Heartbleed, who knows?
Tom Limoncelli http://the-cloud-book.com http://everythingsysadmin.com
P.S. Blackbox was written to safely store the occasional secret file (SSL certs, mostly) in a Puppet repo stored on an in-company source code server.
Even though I personally knew everyone with access to the repo, root access to the repo server, or access to where the backup tapes are stored... it became essential to encrypt those secrets. Honest, I don't trust the people who handle our backup tapes... one of them is me and I'm the least trustworthy person I know.
Even more importantly, now that I could open up the repo to all my coworkers, it enabled me to collaborate across the company. They could read my code, even submit pull requests, and I didn't have to worry that they had access to SSL certs.