[HN Gopher] Git-crypt - transparent file encryption in Git
___________________________________________________________________
Git-crypt - transparent file encryption in Git
Author : yamrzou
Score : 112 points
Date : 2024-11-26 09:45 UTC (1 days ago)
(HTM) web link (www.agwa.name)
(TXT) w3m dump (www.agwa.name)
| asymmetric wrote:
| 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.
| dontdoxxme wrote:
| It sounds like jujutsu is not honoring the filter option, see
| man gitattributes, it even lists encryption as a possible use.
| theamk wrote:
| https://github.com/martinvonz/jj/issues/53
|
| open since 2022
| siroma wrote:
| 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.
| FredPret wrote:
| 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
| zaptheimpaler wrote:
| 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
| nikeee wrote:
| 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
| er4hn wrote:
| 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?
| cube2222 wrote:
| 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.
| usr1106 wrote:
| 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.
| ratorx wrote:
| > 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).
| remram wrote:
| You're describing a private repo. GitHub/GitLab/... have
| that.
| ratorx wrote:
| 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.
| richbell wrote:
| 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.
|
| [0]: https://sobolevn.me/git-secret/
|
| [1]: https://github.com/alin23/Lunar/
| remram wrote:
| 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.
| erinaceousjones wrote:
| 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!
| arccy wrote:
| diffs and merges can use textconv to operate on the decrypted
| file
| remram wrote:
| 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.
| TheRealPomax wrote:
| Now if only it worked on Windows.
| gotimo wrote:
| i just downloaded the windows release and that worked fine for
| me
| TheRealPomax wrote:
| Interesting: it didn't work at all when I tried installing it
| only a few months ago... time to revisit it!
| dheera wrote:
| 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.
| CGamesPlay wrote:
| 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
| pydry wrote:
| This looks really cool.
| esperent wrote:
| > 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?
| yencabulator wrote:
| Don't confuse Electron with Web.
| TheCraiggers wrote:
| 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.
| dontdoxxme wrote:
| 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.
|
| [0]: https://github.com/FiloSottile/passage
| mariusor wrote:
| 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
| dangus wrote:
| 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.
| visualphoenix wrote:
| 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 wrote:
| 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.
| ozim wrote:
| Encryption in git repo from start sounds like an antipattern.
| wolletd wrote:
| 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 wrote:
| 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.
| PittleyDunkin wrote:
| > This product
|
| It's not a product; it's free software. (As is pass; which is
| excellent.)
| latexr wrote:
| 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 wrote:
| 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.
| latexr wrote:
| > 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.
| OrderlyTiamat wrote:
| > > 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!
| latexr wrote:
| 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 wrote:
| 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 wrote:
| 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.
| andreasmetsala wrote:
| That relies on the user configuring git hooks correctly,
| which is a similar problem as noticing that transparent
| decryption is configured correctly.
| tripdout wrote:
| I much prefer sops or age.
| eisbaw wrote:
| git-secrets
| dangus wrote:
| 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.
| prmoustache wrote:
| 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.
| ComputerGuru wrote:
| 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
___________________________________________________________________
(page generated 2024-11-27 23:02 UTC)