5 ms·

Git-crypt – transparent file encryption in Git

119 points by rzk 2y ago

asymmetric 2y ago
Is there anything comparable/support for this in jujutsu? The files git-crypt handles are not added to .gitignore — they’re instead added to .gitattributes. The result is that jj commits them, which is not what you want.
- dontdoxxme 2y ago
  It sounds like jujutsu is not honoring the filter option, see man gitattributes, it even lists encryption as a possible use.
  - theamk 2y ago
    https://github.com/martinvonz/jj/issues/53 https://github.com/martinvonz/jj/issues/53 open since 2022
siroma 2y ago
git-crypt is great. I use it on a daily basis to encrypt code of some of my repositories. Some of the software I write contains industry secrets I don't want GitHub to know or train AI with. I don't trust them in keeping my private repos safe, so I use git-crypt. Honestly works way better than I expected initially. Once you configure it it's pretty seamless.
- FredPret 2y ago
  In your usecase, is a self-rolled Gitea not even more secure and also easier to use? Who knows if your trade secrets get decrypted by an AI years from now
zaptheimpaler 2y ago
How does this compare to mozilla's sops[1]. I've heard sops is also used for this kind of usecase, although it seems to do much more. [1] https://github.com/getsops/sops https://github.com/getsops/sops
nikeee 2y ago
There is also git-agecrypt [1], which is the same but uses age instead of gpg. I've used both, they work pretty well. [1]: https://github.com/vlaci/git-agecrypt https://github.com/vlaci/git-agecrypt
er4hn 2y ago
I'm guessing that because this is encrypting the files to be stored, this means that you cannot view the files via Git forge web UIs, cannot merge conflicting encrypted files, etc. Is that right?
- cube2222 2y ago
  It’s pretty transparent when used with local tooling that uses the git cli under the hood (i.e. editor integrations). Web UIs get a bunch of blobs of course, by design.
- usr1106 2y ago
  Only someone who has the keys can display the cleartext. I don't think any forge has support for that and it don't see the use case for first encrypting and then giving the key to the forge. I store only secrets in encrypted form, so I never had to merge anything. But I'd assume merging should be unaffected because it happens in the work area, i.e. in decrypted form. That it's a different storage format in the repo should not matter.
  - ratorx 2y ago
    > don’t see the use case for first encrypting and then giving the key to the forge You might only want to keep the files secret from the broader internet, rather than a (trusted) forge, which can make the unencrypted secrets available via an UI for eg. authenticated maintainers. These cases would benefit from being able to see the secrets transparently in the UI when logged in. Also, forges having access to e.g. deployment secrets is not that uncommon (e.g. GitHub with deployments via GitHub actions).
    - remram 2y ago
      You're describing a private repo. GitHub/GitLab/... have that.
      - ratorx 2y ago
        Not exactly. A private repo is entirely private. You might have an open source project which has some deployment secrets etc that you want to check in to git. All the code and config is perfectly safe to expose to the internet, but you want to hide a specific file. I think this pattern was common for things like Ansible and Terraform configs and dotfiles.
TheRealPomax 2y ago
Now if only it worked on Windows.
- gotimo 2y ago
  i just downloaded the windows release and that worked fine for me
  - TheRealPomax 2y ago
    Interesting: it didn't work at all when I tried installing it only a few months ago... time to revisit it!
dheera 2y ago
The only thing I don't like about this is if you're not careful it's very easy to accidentally commit a cleartext file. And then goddamn github doesn't let you delete a commit, you can only commit another commit that undiffs the diff. Then you go "fuck it" and rebase, and then find out even that didn't work, then you go delete and recreate the repo. Bleh. And they don't give you the server logs to know if someone has accessed the cleartext file during that time. At this point I just commit .tar.gz.gpg files for things that need to be encrypted, it's easier to not fuck up.
CGamesPlay 2y ago
If you're interested in E2EE git repos, you might be interested in a project I've been maintaining for a few years now: git-remote-restic. It stores the git repository in a restic repository hosted on any untrusted storage. It is designed for secure archival, but it does support multi-user access (no web UI because, of course, it's E2EE). https://github.com/CGamesPlay/git-remote-restic https://github.com/CGamesPlay/git-remote-restic
- pydry 2y ago
  This looks really cool.
- esperent 2y ago
  > no web UI because, of course, it's E2EE I've used E2EE messenger apps over a web ui before, are you sure that's not just a design choice?
  - yencabulator 2y ago
    Don't confuse Electron with Web.
  - CGamesPlay 2y ago
    It’d be technically possible to do it, sure. I meant that in comparison to the linked project, where you can view the file paths of the git repo (but not the file contents) on any off-the-shelf git forge. With mine, its not possible to use an existing web UI.
fooqux 2y ago
I could see this being used to create an interesting password storage system. I already use Pass but the one thing I wish it could do is use different keys for different folders, so that I could setup family accounts. This looks to solve that issue, albeit without the Pass ecosystem.
- dontdoxxme 2y ago
  You'd be better off with passage[0] -- it's a fork of pass but uses age for encryption. You can just make a directory hierarchy with appropriate .age-recipients files at the right levels. [0]: https://github.com/FiloSottile/passage https://github.com/FiloSottile/passage
- mariusor 2y ago
  I think the gopass pass alternative supports different keys for different folders. I haven't checked it in a while but that was the main reason why I was using it
- dangus 2y ago
  IMO, it would be easier to use a more feature-complete password manager like Bitwarden. Then all your non-technical family members can use it like a commercial app while you can Use the CLI or whatever open source tool you want to interact with it. In my opinion, encryption inside git repositories is an anti-pattern that usually results in headaches.
eisbaw 2y ago
git-secrets
visualphoenix 2y ago
Git-crypt is a dead product with numerous unresolved issues and drawbacks. Newer versions of git cause git to crash when invoking git-crypt[0]. It doesn’t scale with users: Off-boarding a key is a commit in git. Since it is trivially easy to rewind a git repo before the revocation commit and then decrypt with the revoked key, this means you need to rotate every key under management when any revoke is performed. It provides the illusion of asymmetric key encryption, but your asymmetric key wraps a shared symmetric key used to encrypt the entire repository. This also means a user could roll the repository back before a key was revoked and steal the symmetric key used to protect the repository and then use that key to decrypt the repository any time in the future. It doesn’t scale with the number of files under management. As a result of how it’s implemented, every invocation is a separate process launch. This means every file triggers an asymmetric unwrap of the symmetric key. If you’re protecting your GPG key with hardware keyfob, decrypting the repository will take a long time. This product seemed like a cool idea for a while but it’s implementation leave much to be desired and has not stood the test of time… Password-store[1] does a better job than git-crypt for single user git based gpg encrypted password management. For multi-user git repo encryption I prefer Mozilla SOPS[2], especially when coupled with something like AWS KMS… But then you might consider stepping up to something like Hashicorp Vault[3] or Infisical[4]. [0] https://github.com/AGWA/git-crypt/issues/273 https://github.com/AGWA/git-crypt/issues/273 [1] https://www.passwordstore.org/ https://www.passwordstore.org/ [2] https://github.com/getsops/sops https://github.com/getsops/sops [3] https://www.vaultproject.io/ https://www.vaultproject.io/ [4] https://infisical.com/ https://infisical.com/
- peterldowns 2y ago
  This is entirely correct. SOPS+kms, or similarly Berglas + GCP Secret Manager, is the right way. Secrets belong in secrets stores, accessible via auditable IAM role grants.
- ozim 2y ago
  Encryption in git repo from start sounds like an antipattern.
  - wolletd 2y ago
tripdout 2y ago
I much prefer sops or age.
dangus 2y ago
If you are thinking of going down this route with this tool or another tool, don’t. If you feel the need to add secrets to a git repository that means you have a problem with your development/deployment workflow. Secrets shouldn’t live in product source code just like configuration shouldn’t live in product source code.
- prmoustache 2y ago
  This, it is a very very bad idea. Other arguments against it: - it opens the door to mistake, i.e. you crypt a bunch of file but easily forget about one. - git is often used in public forges. What is encrypted and not visible with common computing hardware now doesn't mean it will stay like this in the foreseeable future. You should consider any content or communications, you are transferring accross the internet as public as you can't control who is dumping what and when it will be decryptable.
ComputerGuru 2y ago
We have a maintained alternative to storing encrypted secrets in git, but don’t store the (wrapped) encryption key there, thereby avoiding the biggest downfalls seen here. And a first-class api and tooling in multiple languages to obtain said secrets. Here’s the GitHub link for the rust version of SecureStore: https://github.com/neosmart/securestore-rs https://github.com/neosmart/securestore-rs

119 points by rzk 2y ago

Is there anything comparable/support for this in jujutsu? The files git-crypt handles are not added to .gitignore — they’re instead added to .gitattributes. The result is that jj commits them, which is not what you want.

dontdoxxme 2y ago
It sounds like jujutsu is not honoring the filter option, see man gitattributes, it even lists encryption as a possible use.
- theamk 2y ago
  https://github.com/martinvonz/jj/issues/53 https://github.com/martinvonz/jj/issues/53 open since 2022

siroma 2y ago

git-crypt is great. I use it on a daily basis to encrypt code of some of my repositories. Some of the software I write contains industry secrets I don't want GitHub to know or train AI with. I don't trust them in keeping my private repos safe, so I use git-crypt. Honestly works way better than I expected initially. Once you configure it it's pretty seamless.

FredPret 2y ago
In your usecase, is a self-rolled Gitea not even more secure and also easier to use? Who knows if your trade secrets get decrypted by an AI years from now

zaptheimpaler 2y ago

How does this compare to mozilla's sops[1]. I've heard sops is also used for this kind of usecase, although it seems to do much more. [1] https://github.com/getsops/sops https://github.com/getsops/sops

nikeee 2y ago

There is also git-agecrypt [1], which is the same but uses age instead of gpg. I've used both, they work pretty well. [1]: https://github.com/vlaci/git-agecrypt https://github.com/vlaci/git-agecrypt

er4hn 2y ago

I'm guessing that because this is encrypting the files to be stored, this means that you cannot view the files via Git forge web UIs, cannot merge conflicting encrypted files, etc. Is that right?

cube2222 2y ago
It’s pretty transparent when used with local tooling that uses the git cli under the hood (i.e. editor integrations). Web UIs get a bunch of blobs of course, by design.
usr1106 2y ago
Only someone who has the keys can display the cleartext. I don't think any forge has support for that and it don't see the use case for first encrypting and then giving the key to the forge. I store only secrets in encrypted form, so I never had to merge anything. But I'd assume merging should be unaffected because it happens in the work area, i.e. in decrypted form. That it's a different storage format in the repo should not matter.
- ratorx 2y ago
  > don’t see the use case for first encrypting and then giving the key to the forge You might only want to keep the files secret from the broader internet, rather than a (trusted) forge, which can make the unencrypted secrets available via an UI for eg. authenticated maintainers. These cases would benefit from being able to see the secrets transparently in the UI when logged in. Also, forges having access to e.g. deployment secrets is not that uncommon (e.g. GitHub with deployments via GitHub actions).
  - remram 2y ago
    You're describing a private repo. GitHub/GitLab/... have that.
    - ratorx 2y ago
      Not exactly. A private repo is entirely private. You might have an open source project which has some deployment secrets etc that you want to check in to git. All the code and config is perfectly safe to expose to the internet, but you want to hide a specific file. I think this pattern was common for things like Ansible and Terraform configs and dotfiles.

TheRealPomax 2y ago

Now if only it worked on Windows.

gotimo 2y ago
i just downloaded the windows release and that worked fine for me
- TheRealPomax 2y ago
  Interesting: it didn't work at all when I tried installing it only a few months ago... time to revisit it!

dheera 2y ago

The only thing I don't like about this is if you're not careful it's very easy to accidentally commit a cleartext file. And then goddamn github doesn't let you delete a commit, you can only commit another commit that undiffs the diff. Then you go "fuck it" and rebase, and then find out even that didn't work, then you go delete and recreate the repo. Bleh. And they don't give you the server logs to know if someone has accessed the cleartext file during that time. At this point I just commit .tar.gz.gpg files for things that need to be encrypted, it's easier to not fuck up.

CGamesPlay 2y ago

If you're interested in E2EE git repos, you might be interested in a project I've been maintaining for a few years now: git-remote-restic. It stores the git repository in a restic repository hosted on any untrusted storage. It is designed for secure archival, but it does support multi-user access (no web UI because, of course, it's E2EE). https://github.com/CGamesPlay/git-remote-restic https://github.com/CGamesPlay/git-remote-restic

pydry 2y ago
This looks really cool.
esperent 2y ago
> no web UI because, of course, it's E2EE I've used E2EE messenger apps over a web ui before, are you sure that's not just a design choice?
- yencabulator 2y ago
  Don't confuse Electron with Web.
- CGamesPlay 2y ago
  It’d be technically possible to do it, sure. I meant that in comparison to the linked project, where you can view the file paths of the git repo (but not the file contents) on any off-the-shelf git forge. With mine, its not possible to use an existing web UI.

fooqux 2y ago

I could see this being used to create an interesting password storage system. I already use Pass but the one thing I wish it could do is use different keys for different folders, so that I could setup family accounts. This looks to solve that issue, albeit without the Pass ecosystem.

dontdoxxme 2y ago
You'd be better off with passage[0] -- it's a fork of pass but uses age for encryption. You can just make a directory hierarchy with appropriate .age-recipients files at the right levels. [0]: https://github.com/FiloSottile/passage https://github.com/FiloSottile/passage
mariusor 2y ago
I think the gopass pass alternative supports different keys for different folders. I haven't checked it in a while but that was the main reason why I was using it
dangus 2y ago
IMO, it would be easier to use a more feature-complete password manager like Bitwarden. Then all your non-technical family members can use it like a commercial app while you can Use the CLI or whatever open source tool you want to interact with it. In my opinion, encryption inside git repositories is an anti-pattern that usually results in headaches.

eisbaw 2y ago

git-secrets

visualphoenix 2y ago

Git-crypt is a dead product with numerous unresolved issues and drawbacks. Newer versions of git cause git to crash when invoking git-crypt[0]. It doesn’t scale with users: Off-boarding a key is a commit in git. Since it is trivially easy to rewind a git repo before the revocation commit and then decrypt with the revoked key, this means you need to rotate every key under management when any revoke is performed. It provides the illusion of asymmetric key encryption, but your asymmetric key wraps a shared symmetric key used to encrypt the entire repository. This also means a user could roll the repository back before a key was revoked and steal the symmetric key used to protect the repository and then use that key to decrypt the repository any time in the future. It doesn’t scale with the number of files under management. As a result of how it’s implemented, every invocation is a separate process launch. This means every file triggers an asymmetric unwrap of the symmetric key. If you’re protecting your GPG key with hardware keyfob, decrypting the repository will take a long time. This product seemed like a cool idea for a while but it’s implementation leave much to be desired and has not stood the test of time… Password-store[1] does a better job than git-crypt for single user git based gpg encrypted password management. For multi-user git repo encryption I prefer Mozilla SOPS[2], especially when coupled with something like AWS KMS… But then you might consider stepping up to something like Hashicorp Vault[3] or Infisical[4]. [0] https://github.com/AGWA/git-crypt/issues/273 https://github.com/AGWA/git-crypt/issues/273 [1] https://www.passwordstore.org/ https://www.passwordstore.org/ [2] https://github.com/getsops/sops https://github.com/getsops/sops [3] https://www.vaultproject.io/ https://www.vaultproject.io/ [4] https://infisical.com/ https://infisical.com/

peterldowns 2y ago
This is entirely correct. SOPS+kms, or similarly Berglas + GCP Secret Manager, is the right way. Secrets belong in secrets stores, accessible via auditable IAM role grants.
ozim 2y ago
Encryption in git repo from start sounds like an antipattern.
- wolletd 2y ago

tripdout 2y ago

I much prefer sops or age.

dangus 2y ago

If you are thinking of going down this route with this tool or another tool, don’t. If you feel the need to add secrets to a git repository that means you have a problem with your development/deployment workflow. Secrets shouldn’t live in product source code just like configuration shouldn’t live in product source code.

prmoustache 2y ago
This, it is a very very bad idea. Other arguments against it: - it opens the door to mistake, i.e. you crypt a bunch of file but easily forget about one. - git is often used in public forges. What is encrypted and not visible with common computing hardware now doesn't mean it will stay like this in the foreseeable future. You should consider any content or communications, you are transferring accross the internet as public as you can't control who is dumping what and when it will be decryptable.

ComputerGuru 2y ago

We have a maintained alternative to storing encrypted secrets in git, but don’t store the (wrapped) encryption key there, thereby avoiding the biggest downfalls seen here. And a first-class api and tooling in multiple languages to obtain said secrets. Here’s the GitHub link for the rust version of SecureStore: https://github.com/neosmart/securestore-rs https://github.com/neosmart/securestore-rs