Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: git subcommands fail when the .netrc location is given by the NETRC variable #64667

Closed
jnathanh opened this issue Dec 12, 2023 · 3 comments
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@jnathanh
Copy link

Go version

go version go1.21.5 linux/arm64

What operating system and processor architecture are you using (go env)?

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.21.5'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/usr/src/app/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3903612730=/tmp/go-build -gno-record-gcc-switches'

What did you do?

FROM golang:1.21
WORKDIR /usr/src/app

# copy the app including a go.mod file referencing a private golang module in github
COPY . .

# copy the netrc file to a non-default location, and reference it through the NETRC variable
COPY .netrc /usr/src/app/.netrc
ENV NETRC=/usr/src/app/.netrc

RUN go mod download

What did you expect to see?

No errors.

For example, not relying on the NETRC variable and putting the .netrc file in the default location works:

FROM golang:1.21
WORKDIR /usr/src/app

# copy the app including a go.mod file referencing a private golang module in github
COPY . .

# copy the netrc file to the default location, the user's home directory
COPY .netrc /root/.netrc

RUN go mod download

What did you see instead?

go: github.com/jnathanh/go-lib@v0.146.0: reading github.com/jnathanh/go-lib/go.mod at revision v0.146.0: git ls-remote -q origin in /go/pkg/mod/cache/vcs/a2bf11521e6195ec1a067b2d672bdcc6cc8670cca4006fb352c36a3a773967ad: exit status 128:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Confirm the import path was entered correctly.
If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.
The command '/bin/sh -c go mod download' returned a non-zero code: 1

@seankhliao seankhliao changed the title go mod download doesn't use NETRC environment variable cmd/go: support NETRC environment variable Dec 12, 2023
@seankhliao seankhliao added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Dec 12, 2023
@jnathanh
Copy link
Author

@seankhliao I saw your title change. Does that mean the NETRC variable is not currently intended to be supported?

I thought it was supported based on this documentation, but might have misunderstood it.

under private module auth section:

You can store HTTP passwords in a .netrc file, as when passing credentials to private proxies.

under private proxy section:

The location of the file may be set with the NETRC environment variable

@bcmills
Copy link
Contributor

bcmills commented Dec 12, 2023

cmd/go does use the NETRC environment variable:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/auth/netrc.go;l=80;drc=4f1b0a44cb46f3df28f5ef82e5769ebeac1bc493

In this case the problem is that the git command itself is failing to use the NETRC file indicated by the variable.
@jnathanh, can you confirm that git commands executed on the command line are able to access your repo in the configuration using the NETRC variable?

It looks like the git-credential-netrc helper hard-codes the location as ~/.netrc, so you may need to configure your Git credential.helper setting to pass its location as an explicit argument. Perhaps something like:

[credential]
	helper = netrc --file /usr/src/app/.netrc

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Dec 12, 2023
@bcmills bcmills changed the title cmd/go: support NETRC environment variable cmd/go: git subcommands fail when the .netrc location is given by the NETRC variable Dec 12, 2023
@jnathanh
Copy link
Author

Thanks for explaining @bcmills.

I see now that the go command is directly invoking the git command and that there is no connection to the go command's handling of the NETRC variable.

I can confirm that replacing go mod download with git ls-remote MODULE_URL follows the same failure pattern where it works with the default .netrc location, but not with the NETRC environment variable.

I did not test with the git-credential-netrc helper because I think your point was basically "if you configure git to have access, then the go command will have access", and my preference for setting up the authentication is to copy the .netrc file to the user directory (I'm using this in a homebrew formula, which runs installs as a separate user) rather than doing an additional install of the git-credential-netrc helper plus additional configuration.

I'm going to close the issue since it seems I misunderstood the go command's usage of the NETRC var and the command is working as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

3 participants