[visualphoenix]

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

[3] https://www.vaultproject.io/

[4] https://infisical.com/

[peterldowns]

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.

[latexr]

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.

[zimbatm]

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.

[drjasonharrison]

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.

[PittleyDunkin]

> This product

It's not a product; it's free software. (As is pass; which is excellent.)

[latexr]

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.

[ozim]

Encryption in git repo from start sounds like an antipattern.

[wolletd]

Agreed. What kind of data would one want to store encrypted in a git repo besides unencrypted files in the same repo? And why?