Possibility to piggyback on repo's existing authentication?

[kbd]

Would it be possible to use git-crypt in a way that piggybacks off a repo's existing authentication? I.e. a file can be decrypted with git-crypt unlock if the user has commit rights on the repo?

[alerque]

No, git does not have an authentication mechanism at all. It's a distributed VCS, there is no authority on who can commit. Anybody with a copy of the repository on their repository can commit to it. Whether they can push those commits up to some other copy of the repository is a function of the transport method being used (write access to the file system, ssh authentication, https, etc.) and has no particular bearing on the workings of git itself. As such there is no mechanism that could be tied into.

You could possibly jury rig yourself something like this by giving access to a symmetric unlock key over the same channel as you authenticate users and setting up hooks to fetch it, but you need to know you'd be defeating the point of git-crypt — being able to keep secrets inside a repository that has non-secret items in it as well.

[kbd]

Thanks, apologies for not using more precise language. "if the user has commit rights on the repo" should have been "if the user has rights to push to a remote repo". Of course there are issues with that too, since there's nothing special or privileged about a particular remote.

I figured since there are already secrets in use with the authentication to that remote (your password or keys) that there should be some way to reuse that. But as you point out, in that case there are no secrets that anyone with the repo wouldn't know.

You could possibly jury rig yourself something like this by giving access to a symmetric unlock key over the same channel as you authenticate users and setting up hooks to fetch it

Maybe something can be achieved with the github API and a symmetric key stored in a separate private repo.

Anyway, thanks for entertaining my question. Please let me know if you have other ideas, or feel free to close this ticket. Thanks again.

[alerque]

I am not a maintainer on this project, but I can suggest with some confidence that this will be outside the scope of the project. Of course you can put something together with the Github API and a separate private repo, but that implementation will be up to you. The git-crypt project provides a mechanism to do a specific task a specific way. How you make use of that mechanism in production is up to you. There would be a nearly infinite number of ways of distributing credentials depending on your project architecture, platforms of choice, and workflow. My own workflow involves an entirely different stack (User authentication against an LDAP server and secret variables passed via Gitlab to CI runners).

It would be crazy of this project to try to implement this, it's simply the wrong end of the stick. Just as git itself is agnostic about transport and authentication mechanisms, so anything built inside of it should be too. What you are looking for is is a workflow wrapper than makes use of several specific technologies (Github users + ssh + git + git-crypt).

[kbd]

I agree, out of scope for git-crypt. Thanks.

[alerque]

@kbd Your welcome. Can I suggest you close this issue?