cmd/go: panics with GOAUTH='git dir' go get -x

[quantonganh]

Go version

go version devel go1.25-7a2f757c52 Fri Feb 7 02:19:17 2025 -0800 darwin/arm64

Output of go env in your module/workspace:

GOAUTH='git /Users/quantong'

What did you do?

Related: #26232

https://docs.gitlab.com/ee/user/project/use_project_as_go_package.html#authenticate-git-requests-to-private-subgroups

Instead of placing the personal access token in .netrc file, I'm trying to use git authentication method by setting the GOAUTH environment variable to git /Users/quantong.

Assuming that GitLab fix their side to return a 4xx status code when running go get on a private repo in a sub-group (version v16.8.6 currently returns a 200):

GIT_TERMINAL_PROMPT=1 go get -x gitlab.com/namespace/subgroup/project

What did you see happen?

panic: assignment to entry in nil map

goroutine 14 [running]:
net/textproto.MIMEHeader.Add(...)
        /Users/quantong/Code/contrib/go/src/net/textproto/header.go:15
net/http.Header.Add(...)
        /Users/quantong/Code/contrib/go/src/net/http/header.go:31
cmd/go/internal/auth.loadCredential(0x14000034de8, {0x14000730140?, 0x14000440630?})
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/auth/auth.go:156 +0x1d8
cmd/go/internal/auth.runGoAuth(0x14000184780, 0x140003519e0, {0x14000730140, 0x32})
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/auth/auth.go:131 +0x7ac
cmd/go/internal/auth.AddCredentials(0x14000035318?, 0x140002d2780, 0x102c2d794?, {0x14000730140?, 0x140007300c0?})
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/auth/auth.go:44 +0x104
cmd/go/internal/web.get.func1(0x14000035318)
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/web/http.go:173 +0x404
cmd/go/internal/web.get(0x0, 0x14000351950)
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/web/http.go:206 +0x3f4
cmd/go/internal/web.Get(...)
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/web/api.go:186
cmd/go/internal/vcs.repoRootForImportDynamic({0x1400002aea0, 0x21}, 0x1, 0x0)
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/vcs/vcs.go:1294 +0x5c
cmd/go/internal/vcs.RepoRootForImportPath({0x1400002aea0, 0x21}, 0x1, 0x0)
        /Users/quantong/Code/contrib/go/src/cmd/go/internal/vcs/vcs.go:1086 +0xac
...

What did you expect to see?

go get -x a private repo in a subgroup should not panic when using git authentication method.

[gabyhelp]

Related Issues

• cmd/go: go module not forwarding credentials from .netrc to gitlab subgroups #29888 (closed)
• cmd/go: cannot go get package from private Gitlab repo that is in a subgroup #42632 (closed)
• go get fails on private gitlab subgroup #38645 (closed)
• cmd/go: go get fails for long paths #30623 (closed)
• Go modules issue with gitlab groups and sub-groups #34469 (closed)
• cmd/go: "package?go-get=1 404 not found" errors occurs when go get private project in internal private gitlab repository #64223 (closed)
• cmd/go: get fails on gitlab subgroups due to go-import meta tags referring to nonexistent repos #34094 (closed)
• cmd/go: go get panics in GOPATH mode on custom import path with an insecure redirect #34049 (closed)
• cmd/go: "unknown revision" error is misleading if the entire repo can't be found #47028
• cmd/go: get can't auth via ssh for private repo on non-standard port #70026 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

I think it's this line passing a http.Request that doesn't have Header field initialized
https://go.googlesource.com/go/+/37f27fbecd422da9fefb8ae1cc601bc5b4fec44b/src/cmd/go/internal/auth/auth.go#131

[quantonganh]

@seankhliao Yes, I've already created a CL to fix it.

[gopherbot]

Change https://go.dev/cl/647615 mentions this issue: cmd/go: initialize req.Header when loading git credential

[BradErz]

Will this be backported into 1.24? It doesn't just affect git auth; it also affects command auth. We were excited to start using this for the Google artifact registry go proxy, but without the above CL, it doesn't function. Ive tested this CL locally and confirm it does fix the command usecase.

Only netrc is unaffected.

This also makes me question if the tests actually function for this case as all manual reproductions of this resulted in a panic.

[seankhliao]

since this only affects debug mode (-x), i think unlikely?
the standard for backports is generally serious problems with no workaround.

[BradErz]

right.... every test ive run has been in debug mode (i liked to see it returning 2xx in the logs).. sorry for the noise. 🤦

[samthanawalla]

@gopherbot please backport this to go1.24. This is a bug

[gopherbot]

Backport issue(s) opened: #71687 (for 1.24).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[samthanawalla]

We think this should be back-ported because -x is a normal flag for the Go Command. There is no workaround to get -x to work in this case because of the panic.