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 was cool for a while but is flawed… 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, especially when coupled with something like AWS KMS…
But then you might consider stepping up to something like Hashicorp Vault[2] or Infiscal[3].
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).
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.
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.
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.
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?
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.
> 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).
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.
That's right. This is the entire point of an end-to-end encryption scheme, of you are ok with the forge having the key then you have regular private repos.
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.
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 was cool for a while but is flawed… 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, especially when coupled with something like AWS KMS…
But then you might consider stepping up to something like Hashicorp Vault[2] or Infiscal[3].
[0] https://github.com/AGWA/git-crypt/issues/273
[1] https://www.passwordstore.org/
[2] https://www.vaultproject.io/
[3] https://infisical.com/
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.
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
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.
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
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.
It sounds like jujutsu is not honoring the filter option, see man gitattributes, it even lists encryption as a possible use.
https://github.com/martinvonz/jj/issues/53
open since 2022
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.
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
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
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?
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.
> 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).
You're describing a private repo. GitHub/GitLab/... have that.
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.
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.
That's right. This is the entire point of an end-to-end encryption scheme, of you are ok with the forge having the key then you have regular private repos.
diffs and merges can use textconv to operate on the decrypted file
Now if only it worked on Windows.
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.