There are a lot of alternatives in this space (I wrote transcrypt [1] for just this purpose), but I think the killer features here are that you don't need shared credentials since you can have multiple keys, and that it's generic enough to work with multiple VCS's.
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.
Interesting. For storing passwords I use Pass[1] which encrypts everything with GPG and then store it using Git in a private bitbucket repo. Works really well for me. I love the simplicity and ease of use.
One of the things that looked cool about blackbox to me was the support for encrypting the data with multiple keys and managing that.
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 :))
This enables you to control access per subfolder. You can keep your personal passwords in one subfolder and then have various shared subfolders. "pass mv" and "pass cp" will reencrypt with the gpg ids for each subfolder as necessary. You can also "pass init" an existing subfolder to add or remove gpg ids for existing files. See the man page for details [1].
If you can sneak a key into keyrings/live/pubring.gpg, and wait until someone runs blackbox_update_all_files without noticing, you then have access to all files.
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.
I have been looking for a Python solution like this that does not encrypt the entire file, only the actual password entries. I stumbled upon Jaeger a while back which is written in Go. https://github.com/jyap808/jaeger
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?
My apologies; I took the title from the name/tagline of the repo. It won't let me edit the title now, but if a mod wanted to do me the favor and make it say "git/mercurial"...
Oh, I didn't notice the tagline. HN favours the original article's title in most cases, so I suppose a tagline is about as close to a title as we have in this case.
I've corrected the tag line. Thanks for pointing that out!
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?
I find the teams I work with generally end up transmitting secrets over untrusted centralized chat protocols. I'm glad to see folks stepping into this space and popularizing and simplifying this sort of security!
For environment-based configuration values and multi-member teams, I wrote conf_conf [1].
I've slowly been able to train my coworkers to use https://ezcrypt.it/ when sharing secrets rather than putting them directly into untrusted chat. Works great.
I think this tool is useful, but it could be even more useful if the extra manual steps were automated as part of the tool. I can see myself constantly looking for examples to perform each step, rather than just using an intuitive tool.
Personally, I don't use anything. I just check in my .gpg files and open with Emacs, which will decrypt/reencrypt the files for me. Any other editor worth their salt should have similar functionality.
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.
Storing anything of value in the cloud, regardless of encryption, is the very essence of stupidity. How many times does this fact need to be reiterated in the news before people get it.
It would be helpful if you could tell me where you got the impression that I was encouraging use on cloud-storage services. Was it in the README? the code? a post I made on my blog? I ask because I'd like to correct that doc/post/etc. so that others don't get the same impression.
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.
A few years ago, my company was setting up a second office a few hours drive away. They wanted a replicated file share between the two offices. For the initial sync, they drove a NAS from the main office to the satellite. Then they had (openvpn-encrypted) rsyncs on a nightly basis.
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?
Sharing passwords or private keys is inherently risky, but simple necessity always prevails in the end. Acknowledging the risks, developing protocols taking it into account intelligently, is all you can do.
Storing things of value in the cloud, without inspecting and validating that the underlying tech is secure enough is the essence of stupidity.
You store your money in the bank, rather than in your closet right? And they just put that money as a bit in your computerized account on their mainframe, right? How is that any different than a properly secured 'cloud'?
I remember this story, though I forgot exactly how deep it went. I thought it was just compromising certificate authorities, or sneaking in physically to catch part of the stream that's not encrypted like they did with Google. That's irrelevant here because the only computers that would hold decrypted info in the case of Blackbox are those computers which would anyway hold it decrypted without Blackbox.
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.
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.
[1] https://github.com/elasticdog/transcrypt