[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.

[_w1tm]

That relies on the user configuring git hooks correctly, which is a similar problem as noticing that transparent decryption is configured correctly.

[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.

[feikname]

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.

[OrderlyTiamat]

> > 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!

[feikname]

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.

[latexr]

> 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.

[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?

[AndrewDavis]

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.

[ozim]

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.