[Dev Containers] Understand GCM forwarding mechanism

[sam-mfb]

One of the great things about the Dev Containers extension to VS Code versus just "rolling your own" docker image and developing inside it is how Dev Containers seamlessly transfers your git configuration including the git credential manager (GCM) host settings. Being able to develop in a linux container but still rely on GCM on the host, especially for things like FIDO2 and secure storage, is really amazing. Without VS Code Dev Containers you are stuck installing GCM in your linux container which is not easy to get working with an oauth2 flow, especially with FIDO2. (It's doable but you have to use deviceflow and you are still going to have issues with secure storage of the token.)

This has, however, lead to a little bit of antipattern where some developers (myself included) will use VS Code to work in a container even when we don't need (or even want) all the extras VS Code offers, solely to take advantage of gcm forwarding.

I would love a way to do GCM forwarding in any docker container. That's not at all related to this project -- but here is my question that is related:

Would the devs here be willing to share any info on how this is done? Ideally code (or pointers to relevant code), but really even any comments to help me get moving in the right direction would be awesome.

If this type of question is inappropriate for this board, my apologies and feel free to close.

[sam-mfb]

I think I understand the basics of a solution, though there are still some things I can't quite work out which are blocking me putting together a POC.

The basic idea would seem to be to install a simple git credential helper app on the container--call it helper-client--whose sole job is to take git credential commands, pass them to a unix socket, and get the response back from the socket, where the socket in question in bind mounted from the docker host.

On the host side, another service would be running--call it helper-server--that would listen on the socket on the host side, receive any git credential helper requests, pass them on to the git-credential-manager, get the response and pass it back into the socket.

The flow would be something like this:

[*******************container****************************]    |    [*********************************host**********************]
git command <--> git credential helper <--> helper-client <--> helper-server <--> git credential-manager [cmd] <--> gcm 

The helper-client side is fairly straightforward. Any python or node script that can write to a socket will do, and you just put that script as your "credential.helper" argument in the containers .gitconfig.

The helper-server is a little harder. Easy enough to have a service that listens to a socket, but what does it do with the command it receives? Commands from git credential helper will be either "get", "store", or "erase". Let's take "get" as the most common case. When helper-server receives a "get", it can pass it directly on to the host's git-credential-manager, by calling the git credential helper via the CLI as described here. Assuming the host's git is set up to use gcm that should work.

But I don't understand (a) how it can know which host and repo it should target, or (b) what the format of the get command should be to get it to do the correct useHttpPath config.

In particular, if i do something like echo -e "protocol=https\nhost=dev.azure.com\[MyOrg]n" | git credential-manager get I am not redirected to browser auth, even though that is what happens if i call git pull or the like.

Somehow the Dev Containers extension has made this work, but I can't figure out how...

[chrmarti]

We use something like ... | GIT_TERMINAL_PROMPT=0 git credential fill.

[sam-mfb]

@chrmarti , thanks for that pointer. i've started writing out a POC of my proposed solution. i've started with the client side of things and have a working git-credential-helper that can interface with the VS Code Dev Containers IPC socket and in general lets me see what is going on. (you can see it here)

but it seems like my understanding of what is going on is too simplistic. i was imagine that if i called git clone https://[some azure devops repo], my credential helper app would see a get command to the VS Code socket, then a browser prompt, then a reply with the credentials. but instead, all i see is a store command with the oauth token already in the input. my best guess is that in the oauth scenario vs code isn't getting the credential from the credential helper but is instead using askpass. i note there is a GIT_ASKPASS env variable defined in the container by vscode and that appears to communicated with a different socket.

not sure why that's what it's doing (assuming i'm correct). i'm also not seeing a lot in the git docs about how you write an ASKPASS helper.

[chrmarti]

GIT_ASKPASS is from VS Code. I'm actually not sure how that plays together with the credential helper, but it makes sense that you see a combination of both.

[sam-mfb]

@chrmarti, thanks again. yes; that code is here and in other pieces in that directory. it looks like in the azure devops flow at least it gets username and password from askpass -- which is done by passing those requests to a different IPC pipe (that Dev Containers binds in, but is presumably the same pipe used in normal VS Code on the host), and then it sends that password out to the credential helper. so a standalone implementation would require an askpass client and a socket capable of communicating with that as well as the stuff i wrote above.

It looks like the askpass utility just needs to be able to handle git sending it either Username at [url] or Password at [url] and return a string with one or the other.

[sam-mfb]

I have the client and the server pieces working here, but am running into this docker issue. Basically you can't mount a macos socket inside a docker container (except for special cases like /var/run/docker.sock and ssh agent).

How are you guys getting around that? I'm assuming the sockets in the devcontainer aren't actually bound in, but are instead communicating with some other process that than goes out over the network to the host's localhost?

[sam-mfb]

Ok, I've gotten this working. Had to use a TCP connection (at least for mac os) and work through a few other gotchas. My work is posted here and released under the MIT license. I'll close this comment, and anyone who is interested can follow on that repo. Thanks @chrmarti for your help.