4 ms·

Git-crypt – Transparent file encryption in git

29 points by remx 9y ago

tptacek 9y ago
Reprising a comment from a similar tool: 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. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process. https://news.ycombinator.com/item?id=14080007 https://news.ycombinator.com/item?id=14080007
- algesten 9y ago
  It's the same tool.
- HurrdurrHodor 9y ago
  Maybe it's not a great idea for software projects but for keeping personal data in git (the author wrote it for dotfiles) it seems brilliant.
  - tptacek 9y ago
    If your repo isn't, and never will be, part of a team, I don't care what you use to encrypt it, and don't have any criticisms to offer of this tool.
- ekidd 9y ago
  Instead, keep secrets "out of band" and supply them to applications as part of your deployment process. I definitely agree that tools like vault or keywhiz (or automated permission management using AWS roles) are the right way to do things. As as an added plus, a well-designed system can be configured to issue temporary credentials, where every AWS secret and SSH key automatically stops working within 24 hours. And you can log every secret request, and you can set explicit policies about who can access which secrets. Once you see this stuff working, it's hard to imagine ever going back. But unless you're working at a very large scale, you probably still have an offline secret database somewhere, just in case you need to wipe and rebuild your secret management system. Or at the very least, you may need to keep copies of the individual key fragments needed to unlock your vault server's secret database when booting a new vault replica. And at this point, encrypted secrets can still play an important role, especially if access is limited to a tiny number of people. Of course, if one of those people leaves the company, then you need to roll every single secret in your organization. (Which is actually an interesting exercise to do every couple of years, anyway. I increasingly believe all secrets should have TTLs.)
dom0 9y ago
Previous discussion: https://news.ycombinator.com/item?id=14079514 https://news.ycombinator.com/item?id=14079514
sigil 9y ago
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. Couple things I wonder about: 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. 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?
agotterer 9y ago
git-crypt doesn't really seem well maintained any longer. Two alternatives that I've used and like are: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox https://github.com/elasticdog/transcrypt https://github.com/elasticdog/transcrypt
- ausjke 9y ago
  great to know these, thanks!

29 points by remx 9y ago

Reprising a comment from a similar tool: 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. Instead, keep secrets "out of band" and supply them to applications as part of your deployment process. https://news.ycombinator.com/item?id=14080007 https://news.ycombinator.com/item?id=14080007

algesten 9y ago
It's the same tool.
HurrdurrHodor 9y ago
Maybe it's not a great idea for software projects but for keeping personal data in git (the author wrote it for dotfiles) it seems brilliant.
- tptacek 9y ago
  If your repo isn't, and never will be, part of a team, I don't care what you use to encrypt it, and don't have any criticisms to offer of this tool.
ekidd 9y ago
Instead, keep secrets "out of band" and supply them to applications as part of your deployment process. I definitely agree that tools like vault or keywhiz (or automated permission management using AWS roles) are the right way to do things. As as an added plus, a well-designed system can be configured to issue temporary credentials, where every AWS secret and SSH key automatically stops working within 24 hours. And you can log every secret request, and you can set explicit policies about who can access which secrets. Once you see this stuff working, it's hard to imagine ever going back. But unless you're working at a very large scale, you probably still have an offline secret database somewhere, just in case you need to wipe and rebuild your secret management system. Or at the very least, you may need to keep copies of the individual key fragments needed to unlock your vault server's secret database when booting a new vault replica. And at this point, encrypted secrets can still play an important role, especially if access is limited to a tiny number of people. Of course, if one of those people leaves the company, then you need to roll every single secret in your organization. (Which is actually an interesting exercise to do every couple of years, anyway. I increasingly believe all secrets should have TTLs.)

dom0 9y ago

Previous discussion: https://news.ycombinator.com/item?id=14079514 https://news.ycombinator.com/item?id=14079514

sigil 9y ago

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. Couple things I wonder about: 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. 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?

agotterer 9y ago

git-crypt doesn't really seem well maintained any longer. Two alternatives that I've used and like are: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox https://github.com/elasticdog/transcrypt https://github.com/elasticdog/transcrypt

ausjke 9y ago
great to know these, thanks!