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.