Git-crypt – transparent file encryption in Git
agwa.name
agwa.name
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
Secrets belong in secrets stores, accessible via auditable IAM role grants.
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.
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.
It's not a product; it's free software. (As is pass; which is excellent.)
“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.
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.
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.
> "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!
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.
> 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.
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.
I've used E2EE messenger apps over a web ui before, are you sure that's not just a design choice?
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.
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.
Here’s the GitHub link for the rust version of SecureStore: https://github.com/neosmart/securestore-rs
The result is that jj commits them, which is not what you want.
open since 2022
Who knows if your trade secrets get decrypted by an AI years from now
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.
Web UIs get a bunch of blobs of course, by design.
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.
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).
I think this pattern was common for things like Ansible and Terraform configs and dotfiles.
My point is, don't use an end-to-end encryption scheme if you want more than the ends decrypting it.
Don't trust private repos to be private!
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.