CC @bradfitz @FiloSottile @jayconrod

I think the array of possible authentication schemes is too wide, so these should be handled by a local GOPROXY that exposes the unauthenticated protocol to the client, and does whatever authentication you want to the upstream.

I'm starting to think it would be nice to let GOPROXY be a binary that the go tool runs itself, so that a GOPROXY can be made even for small tasks, without having to run a network service on the local machine, which is a lot of friction.

I think a drawback of the local GOPROXY solution is that everyone running go who has to play the authentication game would need not just set some environment variables but would have to obtain / install / keep up-to-date, and make sure go can find and execute that separate program - in addition to setting an environment variable for GOPROXY. It also seems to open an additional security attack vector - at the least, you have to worry what kind of "interesting" compromises would become possible through the local GOPROXY binary. Personally for mTLS I would prefer to be able to tell go where to pick up cert/key/cacert from then deal with creating (?) / setting up additional binary.

Let's get the basic HTTP auth stuff working first (#26232) and then circle back to thinking about even more exotic authentication like TLS client certs.

It would be very useful for us to be able to pass a client certificate to the go tool. I guess this issue is different from #26232, because no text/html is transmitted without an tls handshake. So it cannot be fixed by extending to access-denied page.
I agree with @dmitris to keep the number of local tools small and would argument that if an -insecure flag exists, a -client-cert (or a matching environment variable) would be valid.
I'm looking forward to see updates on this and let me know if I can help in some way.

There is a temporary solution. I use a MITM tool to provide client certificates.
Like this:

mitmdump --listen-host ${ip_address} --listen-port ${port} --ignore-hosts=${whitelist} --set client_certs=${cert}

And set

go env -w GOPRIVATE="your company repo"

I'd really love to be able to use client certificates as well.
Any chance we get this implemented? I'd try to provide a pull request if there's any interest.

Let's get the basic HTTP auth stuff working first (#26232) and then circle back to thinking about even more exotic authentication like TLS client certs.

@rsc Given that #26232, which implemented basic HTTP authentication, is now complete, could we revisit this issue and potentially bring it before the proposal committee?