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