15 ms·
Git-secret – store private data in a Git repo
- tshadwell 10y agoSee also: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox "blackbox by StackExchange"
- aeontech 10y agoNice work! I've been using https://github.com/AGWA/git-crypt https://github.com/AGWA/git-crypt until now, always good to have more alternatives. Can you tell us what is different about your approach with this project?
- ioquatix 10y agoI've started using git-crypt for deploying configuration. It keeps things simple and ensures that keys are not in plain text on bit-bucket which is basically good enough right now.
- deleted 10y ago[deleted]
- ericfrederich 10y agoHmm... 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. 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?
- apetresc 10y agoI have nothing to do with this project, but I think the answer to your question is no - you don't have to re-write history. If the removed party had access to previous revisions signed with his key, they're already "compromised" as far as security is concerned. Whether or not you rewrite history, he already has it. The re-encryption they're referring to is presumably just to protect future revisions (since you would ideally rotate all keys they had access to, git-secret or not, and publish new ones right away).
- TheHippo 10y agoSimilar project, that I personally use quite often: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox
- YesThatTom2 10y agoI'm glad that blackbox is gaining in popularity. Future directions for the project are listed here: https://github.com/StackExchange/blackbox/blob/master/Version2-Ideas.md https://github.com/StackExchange/blackbox/blob/master/Versio...
- gechr 10y agoA 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. 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 uncompressed blob being stored, rather than a compressible textual delta. [1] http://article.gmane.org/gmane.comp.version-control.git/113221 http://article.gmane.org/gmane.comp.version-control.git/1132...
- apetresc 10y agoWhile technically true, the type of data this extension is meant for (small configuration snippets containing sensitive credentials) are both small and rarely-changing. A couple extra bytes in the index won't be a very big deal.
- markcerqueira 10y agoI can imagine a great number of use cases involve encrypting an access key or password making this not a big issue, right?
- runholm 10y agoWhy would someone change a single bit in their key anyway? If keys are replaced, the new key should be generated independent from the old ones.
- Confiks 10y agoI'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`. 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.
- perlgeek 10y agoTo be a bit pedantic, all .yml files can be encrypted with ansible-vault, so also playbooks and roles. There are two things currently that bother me about ansible-vault. The first is that the 'edit' command write a completely new file even if I didn't change anything. And the second is that the diffs in git become useless. I'd love to have a special diff driver for ansible-vault encrypted files that decrypts before diffing when the secret is available.
- Deinumite 10y agoIf you use show instead of edit it doesn't re-encrypt the file. Agreed on the useless diffs however, it makes reviewing pull requests or changes much harder.
- RRRA 10y agoI'm curious, why do you feel the need to encrypt every single file instead of just secrets (to keep reviewing possible)? :)
- Deinumite 10y agoI usually only encrypt var files that contain things like db passwords or something. In our case it made it harder to spot typos in the username for example. I wouldn't encrypt a whole playbook for example.
- 10y ago
- perlgeek 10y ago> When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore. 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.
- stouset 10y agoYes, they can still decrypt old versions. Storing secret keys, API keys, etc. in your git repo is a terrible idea and an antipattern any way you slice it. Keep your secrets out of version control. The quoted advice is extremely bad. If someone who has access to a secret of any importance leaves your team, the only acceptable response is to rotate the secret.
- Tehnix 10y agoYes, he can still decrypt the secrets he had access to before his key was revoked, just as he could have written down those secrets before he was fired. There is no difference really, and the way to solve that is the same for both cases - you change your secrets after such an event.
- seletskiy 10y agoRecently, I've wrote simple tool for storing secrets like passwords in public Git repos using AES cypher: https://github.com/seletskiy/carcosa/ https://github.com/seletskiy/carcosa/
- cs702 10y agoAnother 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. https://github.com/rustyio/git-gpg https://github.com/rustyio/git-gpg Other benefits include architectural simplicity and low footprint: it consists of a single Python script that you add to your executable path.
- y0ghur7_xxx 10y agoThis 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. If you have a github account the script could also get the pubkey directly from the github api... ¹http://superuser.com/questions/576506/how-to-use-ssh-rsa-public-key-to-encrypt-a-text http://superuser.com/questions/576506/how-to-use-ssh-rsa-pub...
- bencord0 10y agoSSH keys aren't really used for encryption. Typical ssh uses some kind of DH construct, with the ssh keypairs just used for authentication. However, stackexchange is the right place to go if you want to use asymmetric secret storage in git. https://github.com/stackexchange/blackbox https://github.com/stackexchange/blackbox
- talaketu 10y agoSee https://www.netmeister.org/blog/sharing-secrets-using-ssh-keys.html https://www.netmeister.org/blog/sharing-secrets-using-ssh-ke... and https://github.com/jschauma/jass https://github.com/jschauma/jass
- jedberg 10y agoThis 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. 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. [0] https://github.com/hashicorp/vault https://github.com/hashicorp/vault
- Kinnard 10y agoPerhaps it's an alternative practice/behavior rather than a "bad" practice?
- tptacek 10y agoIt's a bad practice, because git makes keys practically irrevocable. It's not enough to rotate encryption keys, because the old ciphertexts are in the git history; you have to rotate the underlying secrets as well (people don't do this and shouldn't have to). Don't store encrypted secrets in git if you can avoid it.
- whisk3rs 10y agowhy shouldn't people have to rotate the underlying secrets? a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored. seems like we should be making it easier to rotate secret values often and automatically.
- sumitgt 10y agoExactly!. The page says "When someone is out - just delete his public key, reencrypt the files, and he won’t be able to decrypt secrets anymore." but doesn't talk about rotating the secrets. This practice seems unnecessary to me.
- siliconc0w 10y agoThe problem is you need some repository to store this information and it's incredibly helpful to store the configuration along with the code. If someone has access to a shared secret and then shouldn't you should assume the secret is now compromised and rotate it. Rotating the keys doesn't solve this problem.
- passive 10y agoIf you need to do this, I would recommend looking at Transcrypt: https://github.com/elasticdog/transcrypt https://github.com/elasticdog/transcrypt
- fibo 10y agoI am using keybase.io to store soft secrets like the coveralls.io token. Let me share my simple use case: http://g14n.info/2014/07/my-keybase-experience/ http://g14n.info/2014/07/my-keybase-experience/
- miles_matthias 10y agoI've been using https://github.com/ahoward/sekrets https://github.com/ahoward/sekrets in private repos for years. Great tool. I definitely agree this should be used with heavy caution and only in private repos.
- stouset 10y agoThis should not even be used in private repos unless the only person who will ever access the repo is you.
- adamkochanowicz 10y agoI used to put .gpg files in my repos that stored sensitive information like database passwords and such. 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.
- marcosnils 10y agoSome cross platform tool that we've developed for our company which has some nice features https://github.com/franela/vault https://github.com/franela/vault
- beefsack 10y agoIf all you have is a hammer, everything looks like a nail.
- deleted 10y ago[deleted]
- nsaje 10y agoAt 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. Access control is managed through AWS KMS key policies, with EC2 instances running the applications having permissions to decrypt the secrets. Blog post about this will follow soon. [0] https://github.com/Zemanta/py-secretcrypt https://github.com/Zemanta/py-secretcrypt [1] https://github.com/Zemanta/go-secretcrypt https://github.com/Zemanta/go-secretcrypt