@rsc, opinions on this?

Reading .netrc seems a bit hacky.

How is that hacky if the user who created the .netrc file (%HOME%\_netrc in Windows) is running a process which needs to access one of those domains? ...as long as you don't post the contents to Twitter or something ;-)

Another (not even mutually exclusive) option would be to parse ~/.gitconfig:

[url "ssh://git@bitbucket.org/"]
        insteadOf = https://bitbucket.org/
[url "ssh://git@github.com/"]
        insteadOf = https://github.com/

It's hacky because it's not the go command's job to recreate the functionality of other tools. We're not reading .gitconfig and we're not reading .netrc, and that's good.

That said, I think the go command itself handles bitbucketVCS just fine - for an auth failure it falls back to invoking git/hg directly, which is the perfect way to respect .netrc without parsing .netrc - and the x/tools/go/vcs copy is just out of date. Perhaps it is enough for someone to refresh the x/tools copy.

... So govendor sync is calling the wrong X/tools function?

No, I think x/tools/go/vcs (which is a copy of code internal to the go command) is out of date and needs to be updated.

Perhaps the go command should vendor this library so that there is one version of this code to maintain?

There will always be two copies to maintain. The go command is the primary source here.

This just needs to be refreshed from the cmd/go master.

I think go get should respect .netrc file at least while fetching meta-data.
My company's code repos (derived from Gitlab) that only authorized user access any URL.

This package has been deprecated in #57051 and won't receive further development, so closing this as not planned.