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
[1] https://www.passwordstore.org/
[2] https://github.com/getsops/sops
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.
To add to your point, see the “current status” section on the website:
> The latest version of git-crypt is 0.7.0, released on 2022-04-21. git-crypt aims to be bug-free and reliable, meaning it shouldn't crash, malfunction, or expose your confidential data. However, it has not yet reached maturity, meaning it is not as documented, featureful, or easy-to-use as it should be. Additionally, there may be backwards-incompatible changes introduced before version 1.0.
Last updated over two years ago and described by the authors even then as half-baked.
Another major flaw:
Transparent decryption sounds nice. Until you commit decrypted secrets by mistake.
Because the encryption/decryption is transparent, you won't notice if the .gitattributes pattern-matching is wrong until it's too late.
I did this myself and saw it happen in the wild as well.
using pre-commit with a hook to prevent secrets from being committed provides a bit more help preventing this mistake. Nor full-proof because you could always commit say a base64 encoded .env file.
That relies on the user configuring git hooks correctly, which is a similar problem as noticing that transparent decryption is configured correctly.
> This product
It's not a product; it's free software. (As is pass; which is excellent.)
That type of pedantry is why people make fun of the free software movement. And if programmers don’t take it seriously, good luck convincing anyone else. Pick your battles.
“Product” doesn’t mean closed-source or paid, it’s simply the result of an action or process. The product of your cooking at home is a meal that feeds you. The product of your coding effort is a binary, a script, a set of files, or something else that satisfies a need. It doesn’t have to be a business need. A product that doesn’t sell or isn’t made to be sold is still a product.
Yet no one calls their homemade food a product and offer to others for free calling it that. The semantic prominence of a commercial product would prevail as the first thing that comes to mind for anyone because that's also one of the meanings of the word product.
It's simply confusing to call something that can and is commonly monetized as a (commercial) product - that is, software - and not expect others to believe its something paid.
e.g. "Apache is a product for serving web pages" would surely be read by majority of people not familiar with Apache as if it's paid.
> That type of pedantry is why people make fun of the free software movement.
No. They make fun because people use terms like open-source to mean more than just a source that is open.
Or free and open-source whereas free, like product can also have more than one meaning. And they expect people unfamiliar to understand it means free as in liberty not as in price.
These are confusing, just like using the word product for unpaid software done that is done in spare time and has no commercial support whatsover.
If I could decide, the movement would have been called something like "source code free to see and to modify (and redistribute, if applicable)". Lengthy, yes, but also pretty clear.
> > That type of pedantry is why people make fun of the free software movement.
> "source code free to see and to modify (and redistribute, if applicable)"
You have to see the humor in putting both of these in the same comment, right? That's a prime example of what they're talking about!
As I said, it's not the pedantry that gets the free software movement to be made fun of, its the overloading of terms and then having to overly explain them.
Creative Commons is very clear in its license and it - rightfully - doesn't get as much complaint as open-source evangelists about its lingo.
Having to say "but technically a product is anything that is produced" to go against a expected reading and then complain about pedantry in the same comment is way more humorous as it's a prime example of what they're talking about.
> Yet no one calls their homemade food a product
Just like no one calls food at a restaurant a product, despite it being paid. But it is a product. You’re nitpicking the example to explain a concept instead of the argument.
> No. They make fun because people use terms like open-source to mean more than just a source that is open.
That is nonsensical. It’s like saying people make fun of Lord of the Rings fans because of how they pronounce Balrog. You need to be inside the community to understand the nuance of it in the first place.
While you believe people make fun of the movement for something so subtle, you won’t be able to change their mind.
> Lengthy, yes, but also pretty clear.
Also pretty dead in the water. No one would have called it that, ever. With such a name you’d either have doomed the movement before it started or everyone would have called it something else instead.
Encryption in git repo from start sounds like an antipattern.
Agreed. What kind of data would one want to store encrypted in a git repo besides unencrypted files in the same repo? And why?
It's not uncommon in configuration management. Ansible has ansible-vault which encrypts secrets you then commit. When you need to use them you decrypt them and run your ansible commands.
https://docs.ansible.com/ansible/latest/cli/ansible-vault.ht...
It suffers the same problem as any other secrets management in git. If the decryption key leaks, even if your repo hasn't, you have to rotate every secret in case the repo is ever leaked in the future.
Even if Ansible has it that doesn’t mean people should put secrets in GIT repos. It just means a lot of Ansible users wanted it - and from my POV users don’t want correct features, they want what they feel they need.
GIT repo or config files should have references or secret names that should be filled in on the machine where scripts are running. Ideally secrets should never ever be transmitted even encrypted.
That’s people are lazy and don’t want to do proper setup is their problem.
There is nothing that should be encrypted belonging in GIT repo because secrets and encrypted stuff is not meant to be shared/dispersed. Where GIT main purpose is to share and distribute code.
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).
> 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?
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.
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
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.
There is also git-agecrypt [1], which is the same but uses age instead of gpg. I've used both, they work pretty well.
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.
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
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.
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.
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
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.
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.
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.
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.
We started using git-crypt hurriedly and out of necessity/paranoia from the time we heard that our GitLab instance could've been compromised due to a "anyone can be admin" class exploit that had just been disclosed. This must've been a fair few years ago.
Don't trust private repos to be private!
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.
So a private submodule?
My point is, don't use an end-to-end encryption scheme if you want more than the ends decrypting it.
I believe git-secret[0] does what you describe. The author of Lunar[1] uses it to hide the private elements in a public repo.
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.
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.
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.
Now if only it worked on Windows.
i just downloaded the windows release and that worked fine for me
Interesting: it didn't work at all when I tried installing it only a few months ago... time to revisit it!