This project scares me because it helps foster a bad practice -- keeping secrets in a repo. You really shouldn't be keeping secrets in the repo.<p>You should be using a secrets service that is designed for such a purpose, like Hashicorp's Vault[0], so that you never have to keep a secret in the code.<p>[0] <a href="https://github.com/hashicorp/vault" rel="nofollow">https://github.com/hashicorp/vault</a>
Nice work!<p>I've been using <a href="https://github.com/AGWA/git-crypt" rel="nofollow">https://github.com/AGWA/git-crypt</a> until now, always good to have more alternatives.<p>Can you tell us what is different about your approach with this project?
I've been using ansible-vault to solve this problem in our infrastructure repository. A symmetric vault key is encrypted using gpg, and Ansible's vault_password_file is set to to an executable shell script containing `gpg --batch --use-agent --descrypt vault_key.gpg`.<p>Very specific to Ansible, but works fine. It's a shame only files containing variables (we're using group_vars) can be encrypted, and not arbitrary files or templates.
Another tool worth looking into is git-gpg, which allows you to store encrypted git repositories on third-party / potentially insecure servers, but unlike this tool it stores all changes to source files as compressible textual deltas (a key reason for using git in the first place). The repository is encrypted remotely but the local version has no encrypted blobs inside.<p><a href="https://github.com/rustyio/git-gpg" rel="nofollow">https://github.com/rustyio/git-gpg</a><p>Other benefits include architectural simplicity and low footprint: it consists of a single Python script that you add to your executable path.
Similar project, that I personally use quite often: <a href="https://github.com/StackExchange/blackbox" rel="nofollow">https://github.com/StackExchange/blackbox</a>
This should really work with ssh public/private keys¹. Public keys are probably already on the box the git server runs on, and users already have them generated to access git - no need to generate separate gpg keys.<p>If you have a github account the script could also get the pubkey directly from the github api...<p>¹<a href="http://superuser.com/questions/576506/how-to-use-ssh-rsa-public-key-to-encrypt-a-text" rel="nofollow">http://superuser.com/questions/576506/how-to-use-ssh-rsa-pub...</a>
I used to put .gpg files in my repos that stored sensitive information like database passwords and such.<p>I don't do that anymore. The main problem as I saw it was that you basically liberate your security to an environment you can't monitor or send rejections to (if someone downloads your gpg file). Compare this to an ssh server which affords both those abilities.
> When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore.<p>But they still can encrypt old versions stored in git, no? Do you change all secrets when somebody leaves the team/company? I guess that'd be best practice, but I have no idea how often that's done out there.
A word of warning to those considering using this. While I completely understand why people might want to encrypt/decrypt files within their public Git repositories, doing so doesn't come for free.<p>As Junio C Hamano explains more eloquently and in greater depth here[1], one thing to bear in mind with this (and similar) tools is that they store the managed files as binary blobs, regardless of their original format, meaning that a change to the source file of even a single bit will result in an entirely different <i>uncompressed</i> blob being stored, rather than a compressible textual delta.<p>[1] <a href="http://article.gmane.org/gmane.comp.version-control.git/113221" rel="nofollow">http://article.gmane.org/gmane.comp.version-control.git/1132...</a>
At Zemanta, we developed py-secretcrypt[0] and go-secretcrypt[1] for keeping secrets encrypted with Amazon KMS (Key Management Service) in our repos. They are then decrypted on the fly by the application.<p>Access control is managed through AWS KMS key policies, with EC2 instances running the applications having permissions to decrypt the secrets.<p>Blog post about this will follow soon.<p>[0] <a href="https://github.com/Zemanta/py-secretcrypt" rel="nofollow">https://github.com/Zemanta/py-secretcrypt</a><p>[1] <a href="https://github.com/Zemanta/go-secretcrypt" rel="nofollow">https://github.com/Zemanta/go-secretcrypt</a>
See also: <a href="https://github.com/StackExchange/blackbox" rel="nofollow">https://github.com/StackExchange/blackbox</a> "blackbox by StackExchange"
Hmm... adding access controls to Git? I'm not sure how I feel about this.
I like how Git is low level and stays away from all of that stuff leaving it up to wrappers like GitLab, GitHub, Gerrit, etc.<p>When you remove someone from the list of users does it have to go and re-write history? Isn't that a big no-no in Git?
If you need to do this, I would recommend looking at Transcrypt: <a href="https://github.com/elasticdog/transcrypt" rel="nofollow">https://github.com/elasticdog/transcrypt</a>
I am using keybase.io to store soft secrets like the coveralls.io token. Let me share my simple use case: <a href="http://g14n.info/2014/07/my-keybase-experience/" rel="nofollow">http://g14n.info/2014/07/my-keybase-experience/</a>
Some cross platform tool that we've developed for our company which has some nice features<p><a href="https://github.com/franela/vault" rel="nofollow">https://github.com/franela/vault</a>
I've been using <a href="https://github.com/ahoward/sekrets" rel="nofollow">https://github.com/ahoward/sekrets</a> in private repos for years. Great tool.<p>I definitely agree this should be used with heavy caution and only in private repos.
Recently, I've wrote simple tool for storing secrets like passwords in public Git repos using AES cypher: <a href="https://github.com/seletskiy/carcosa/" rel="nofollow">https://github.com/seletskiy/carcosa/</a>