Reprising a comment from a similar tool:<p>Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times.<p>Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.<p><a href="https://news.ycombinator.com/item?id=14080007" rel="nofollow">https://news.ycombinator.com/item?id=14080007</a>
I know tptacek regards this as a security antipattern (he's usually right), but I do it anyway for smaller projects. It's better than committing plaintext secrets to a repo somewhere.<p>Couple things I wonder about:<p>1. I don't understand why git-crypt is written in C, when a shorter shell script that calls out to openssl(1) and gpg(1) would seem to suffice.<p>2. The symmetric key mode isn't ideal -- the gpg mode is better -- but up until OpenSSH 6.7 you couldn't easily forward gpg-agent's unix domain socket, which you need for working with a git checkout on a remote machine. There are also some issues with the gpg-agent protocol last I checked. Has anyone actually gotten gpg-agent forwarding to work?
git-crypt doesn't really seem well maintained any longer.<p>Two alternatives that I've used and like are:<p><a href="https://github.com/StackExchange/blackbox" rel="nofollow">https://github.com/StackExchange/blackbox</a><p><a href="https://github.com/elasticdog/transcrypt" rel="nofollow">https://github.com/elasticdog/transcrypt</a>