Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: cmd/go: add a sub command to manage authentication #40189
The current state
The Go command utilitizes the ~/.netrc file, both implicitly and explicitly, to authenticate against remote servers when downloading Go code.
Go uses ~/.netrc implicitly when using "direct" downloads because git uses libcurl to fetch dependencies through https which in turn uses the ~/.netrc file to forward credentials.
Go uses ~/.netrc explicitly when authenticating against a GOPROXY server by looking for a matching "machine" URL with a valid login and password and forwards those credentials as a BasicAuth header.
A Go programmer who wants to set their credentials (whether against a proxy or VCS) must know how to create/edit the .netrc file in their home directory manually. This is has a few problems:
Many languages and tools abstract authentication management in their command line:
And the list goes on.
Go should provide a more pleasant, and less error prone, way to configure user's credentials for downloading private module dependencies.
Specifically, Go should be able to create and edit the ~/.netrc file without the user's direct manipulation of it.
Go should be able to add/edit/remove specific lines in the ~/.netrc through the Go command line.
Please note: The following syntax is arbitrary and can definitely be changed. This proposal is more about getting agreement that we should let the Go command manage the .netrc file and is not picky about what the syntax will look like.
That said, suggestion on what the command syntax would look like is welcome here.
To address a couple points:
That said, I'm not sure we should rely on
#26232 is a feature request for an extensible authentication mechanism in the style of
That would provide a lot of flexibility, but I'm not sure it would make the user experience any simpler. Perhaps a
Agreed. The GOAUTH env var would probably be even more complex for users to configure so a
Could we not have a
That said, I would prefer to keep the
From a UX perspective, I don't think is a good idea. A nice gain of having a GOPROXY is that we can tell users they don't need to have "git" and other VCS binaries in their build step because a GOPROXY will take care of module fetching for you. If we had to tell them they need to make sure they have "git" just to authenticate against a GOPROXY, it feels like a step in the wrong direction. But definitely correct me if I missed something.
Agreed. But telling Go developers to install a third party tool just so they can make Go understand and pass credentials is not the most ideal. Though it's certainly better than telling Go developers to hand craft a ~/.netrc file.
Other than the above, I see two options:
I like the idea of a
According to the Cloud Functions documentation for Go, the only way to use a private Go module is to vendor it (which is very constraining).
Another problem, as it pertains to HTTP Basic Auth, is that (in accordance with RFC 7617) the