
Blackbox: Safely store secrets in Git - akerl_
https://github.com/StackExchange/blackbox
======
elasticdog
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.

[1]
[https://github.com/elasticdog/transcrypt](https://github.com/elasticdog/transcrypt)

------
crdoconnor
Ansible handles this issue very cleanly with a feature called "vault":
[http://docs.ansible.com/playbooks_vault.html](http://docs.ansible.com/playbooks_vault.html)

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.

~~~
YesThatTom2
The README.md explains how to do this cleanly with Puppet and Hiera.

------
robinhoodexe
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.

[1][http://www.zx2c4.com/projects/password-
store/](http://www.zx2c4.com/projects/password-store/)

~~~
akerl_
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 :))

~~~
dnerdy
You can specify multiple gpg ids when using "pass init":

    
    
      pass init [-p sub-folder] user1@example.com user2@example.com
    

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].

[1] [http://git.zx2c4.com/password-
store/about/](http://git.zx2c4.com/password-store/about/)

------
vanilla
git-crypt[1] also does per file encryption

[1]: [https://www.agwa.name/projects/git-
crypt/](https://www.agwa.name/projects/git-crypt/)

~~~
agwa
And the upcoming version (which is overdue--I've been busy) will support
encrypting with GPG with multiple recipients, like BlackBox.

------
A1kmm
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.

------
defunct
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](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?

------
jordigh
Why does the HN title say "in git"? This tool seems to be specifically built
to handle hg as well. A pleasant surprise for hg users like me. :-)

~~~
akerl_
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"...

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

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

------
kassemi
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].

[1]
[https://github.com/jkassemi/conf_conf](https://github.com/jkassemi/conf_conf)

~~~
elasticdog
I've slowly been able to train my coworkers to use
[https://ezcrypt.it/](https://ezcrypt.it/) when sharing secrets rather than
putting them directly into untrusted chat. Works great.

------
nchelluri
Vaguely along the same lines, I use something similar for keeping my journal.
Because I'm paranoid. :P

I create/view/edit files and then I push the directory containing them to some
git remote.

[https://gist.github.com/anonymous/df1ba398dd4e4748c6cd](https://gist.github.com/anonymous/df1ba398dd4e4748c6cd)

Usage commands at the bottom.

------
dmourati
We used something similar for Puppet: [https://github.com/TomPoulton/hiera-
eyaml](https://github.com/TomPoulton/hiera-eyaml)

Really neat thing was that you could inline encrypt just the secretes making
the rest of the Puppet module viewable and comprehensible.

~~~
Terretta
Looks like the read me mentions this for strings.

------
peterwwillis
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.

------
perlancar
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.

~~~
YesThatTom2
Good to know!

This was originally written for Puppet files. The Puppet Master needs to have
a separate key that permits it to decrypt all the files.

------
mafro
Shameless plug for a very simple tar-like CLI app done in Python:

[https://github.com/mafrosis/sesame](https://github.com/mafrosis/sesame)

------
scosman
why not just use openssl or another command line tool?

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

~~~
elasticdog
That's essentially what I've automated with transcrypt (which uses Git's
clean/smudge filters) to do that for you transparently:

[https://github.com/elasticdog/transcrypt](https://github.com/elasticdog/transcrypt)

------
rphillips
Interesting... Very similar to my golang project.

[https://github.com/rphillips/gosec](https://github.com/rphillips/gosec)

------
pjjw
additional close system:
[https://github.com/jschauma/jass](https://github.com/jschauma/jass)

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.

------
miles_matthias
we use
[https://github.com/ahoward/sekrets](https://github.com/ahoward/sekrets) at
dojo4. love it.

------
deadponies
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.

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

~~~
e12e
Technically, public key cryptography _is_ a (set of) protocols for sharing
secret keys.

