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
cmd/go: .netrc credentials are not forward to GOPROXY if they do not contain password #40215
Go currently allows a user to forward credentials to a GOPROXY using a .netrc file. However, if I specify my .netrc file as follows:
Go will silently fail and will not send the credentials to myproxy.com unless I explicitly put
In other words, I must have both "login" and "password" values.
On the other hand,
What version of Go are you using (
Thanks for opening this.
What's the correct behavior here? Should we report an error for a netrc file like this (probably only when we would contact the machine in question)? Or should we send a request with a username and no password? The former seems more correct to me, but we should be consistent with other systems.
@bcmills at least for GitHub, that is I believe what happens. To test this out, you can use a GitHub token to get your profile information like so:
From the verbose output, you can see the Authorization header which then you can decode its base64 value and see that it looks like this:
So the token is basically the basic auth user, and there is no password after the
Finally, you can confirm that the GitHub API was happy with this and it successfully returns your profile info based on that token.
To be honest, I don't know if this behavior is intentional, accidental, or just unique to GitHub. I just noticed that the .netrc file has always worked against GitHub like this and was surprised to see that Go didn't follow the same rules when forwarding credentials to a GOPROXY and had to dig into the code to find out why.
I'd be interested to hear something more authoritative, as well, but after surveying the behaviors of other tools these are the main options I see (not all mutually exclusive):
There are several different things to consider:
When I started writing this, my preference was leaning in the direction of the
The HTTP tools, OTOH, seem to provide competing interpretations of what may or may not represent an empty password in the
Even though they agree about how to represent an empty password via HTTP Basic Auth, they do not agree amongst themselves what constitutes an empty or missing password in the
Others might be able to offer counter examples, but considering what appears to me to be the historical (relative) consistency in the interpretation of the absence of the
However, if an empty string password is then obtained by some other means, I think
Notes on the above:
One last note: I should also clarify my apparently contradictory comments above about about how
$ http --verbose --ignore-netrc 'http://email@example.com:7777/'