Re: [RFC/PATCH] connect: add GIT_SSH_{SEND,RECEIVE}{,_COMMAND} env variables
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jan 4, 2018, 10:10 UTC
- Message-ID
- <87a7xuc4ty.fsf@evledraar.gmail.com>
- In-Reply-To
- <20180104044230.GA12113@sigill.intra.peff.net>
On Thu, Jan 04 2018, Jeff King jotted:
Show 26 quoted lines
> On Thu, Jan 04, 2018 at 01:08:28AM +0100, Ævar Arnfjörð Bjarmason wrote: > >> Hopefully this is clearer, and depending on how the rest of the >> discussion goes I'll submit v2 with something like this in the commit >> message: >> >> SSH keys A and B are known to the remote service, and used to identify >> two different users. >> >> A can only push to repository X, and B can only fetch from repository Y. >> >> Thus, if you have a script that does: >> >> GIT_SSH_COMMAND="ssh -i A -i B" git ... >> >> It'll always fail for pulling from X, and pushing to Y. Supply: >> >> GIT_SSH_COMMAND="ssh -i B -i A" git ... >> >> And now pulling will work, but pushing won't. > > I get that you may have two different keys to go with two different > identities on a remote system. But I'm not sure I understand why > "sending" or "receiving" is the right way to split those up. Wouldn't > you also sometimes want to fetch from repository X? IOW, wouldn't you > want to tie identity "A" to repository "X", and "B" to repository "Y?
That's badly explained, sorry, when I say "push" I mean "push and/or pull".
I don't know about Github, but on Gitlab when you provision a deploy key and associate it with a repo it must be *globally* rw or ro, there's no way to on a per-repo basis say it should be rw ro.
I have a job that's fetching a bunch of repos to review code in them (for auditing purposes). It then commits the results of that review to other git repos.
Thus I want to have a ro key to all those reviewed repos, but rw keys to the audit repo itself (and it'll also pull with the rw key).
Hence this patch, I thought *maybe* others would be interested in this since it seems to me to be an easy thing to run into with these ssh-key based hosting providers, but maybe not.
Show 6 quoted lines
>> So now I just have a GIT_SSH_COMMAND that dispatches to different keys >> depending on the operation, as noted in the commit message, and I can >> assure you that without that logic it doesn't work. > > You mentioned host aliases later, which is the solution I've seen in the > wild. And then you can map each remote to a different host alias.