go: cmd/go/internal/modfetch: treat malformed versions as “not found” on the proxy path

For Go 1.11 and 1.12, I have in my go.mod something like:

replace (
        github.com/lxn/walk => golang.zx2c4.com/wireguard/windows pkg/walk
        github.com/lxn/win => golang.zx2c4.com/wireguard/windows pkg/walk-win
)

I use this to indicate that usage of github.com/lxn/walk should be replaced with the latest contents of a branch called pkg/walk from golang.zx2c4.com/wireguard/windows.

With 1.13beta1, this now breaks with a message:

/home/zx2c4/Projects/wireguard-windows/go.mod:16: replace golang.zx2c4.com/wireguard/windows: version "pkg/walk" invalid: version "pkg/walk" invalid: disallowed version string
/home/zx2c4/Projects/wireguard-windows/go.mod:17: replace golang.zx2c4.com/wireguard/windows: version "pkg/walk-win" invalid: version "pkg/walk-win" invalid: disallowed version string

This poses a significant problem.

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 19
  • Comments: 36 (28 by maintainers)

Commits related to this issue

Most upvoted comments

Any chance that this gets fixed at any point? Slashes in branch names are very common and it’s frustrating to have to work around this limitation all the time.

Are slashes in git branch names very common?

Yes, extremely common. For example, some projects use it to denote the owner of the branch jd/something. Others use it for particular version partions. One of the most common ways of serving git repos to groups is a piece of software called gitolite, perhaps you’ve heard of it. One of its key features is that it can give granular permissions to branches based on a / hierarchy. This in turn matches the actual way git stores tags: in a directory hierarchy, with / being the directory separator.

To add to my last comment, the convention is even documented here: https://github.com/ipfs/community/blob/master/CONTRIBUTING_GO.md#branch-names

If you are working on a new feature, prefix your branch name with feat/. If you are fixing an issue, fix/. If you are simply adding tests, test/. If you are adding documentation, doc/. If your changeset doesn’t fall into one of these categories, use your best judgement and come up with your own short prefix.

Are slashes in git branch names very common?

As much as I don’t personally use them, I’m afraid they are common. Where I work, pretty much everyone works in branches like feat/some-feature or fix/some-bug. For example: https://github.com/ipfs/go-ipfs/branches

@elgs this issue is about interacting with branches that have a forward slash (/) in them - e.g. branch/name.

It seems it works as of go 1.20.1. I created several branches, all, mysql, sqlite3, and etc., loading only corresponding drivers. And I was able to install the different branches by:

$ go install github.com/elgs/gosqlapi@mysql
$ go install github.com/elgs/gosqlapi@sqlite3
$ go install github.com/elgs/gosqlapi@all

I am quite satisfied as it is. But I am not sure if I overlooked anything.

This bug also affects module imports from a subdirectory of another module.

Here’s an example tree for a repo:

github.com/foo/bar
├── pkg
│       └── baz
│           └── go.mod
└── go.mod

If I were to import package github.com/foo/bar/pkg/baz then go would try to fetch tag pkg/baz/v1.0.0 automatically (that would fail).

What’re the next steps for that one - do we want to fix go or proxy (athens)?

I agree that changes here are too subtle for Go 1.13. For Go 1.14 the first question is “should we make direct mode and proxy mode match as far as what they accept for versions” and the second is “if so, how? restrict direct mode or loosen proxy mode?”

Are slashes in git branch names very common?

@zx2c4, can you confirm that setting GOPROXY=direct continues to allow the branch-names in question? (That probably determines whether this gets the release-blocker label.)

Set GOPROXY=direct works for me:

cuonglm :: /tmp/test » GOPROXY=direct go mod tidy
golang.zx2c4.com/wireguard/windows pkg/walk
go: finding golang.zx2c4.com/wireguard/windows pkg/walk
golang.zx2c4.com/wireguard/windows pkg/walk-win
go: finding golang.zx2c4.com/wireguard/windows pkg/walk-win

@bcmills @jayconrod I think this is a side-effect of changing GOPROXY.

$ GOOS=windows GOPROXY=direct GONOSUM=.* go1.13beta get golang.zx2c4.com/wireguard/windows@pkg/walk
go: finding golang.zx2c4.com/wireguard/windows pkg/walk

The problem can be reproducible with go1.12 if GOPROXY is set.

GOOS=windows GOPROXY=https://proxy.golang.org GONOSUM=.* go get golang.zx2c4.com/wireguard/windows@pkg/walk
go: finding golang.zx2c4.com/wireguard/windows pkg/walk
go: finding golang.zx2c4.com/wireguard pkg/walk
go: finding golang.zx2c4.com pkg/walk
go get golang.zx2c4.com/wireguard/windows@pkg/walk: disallowed version string "pkg/walk"

@utrack try the -x flag to see how the go command works with the proxy. That will show the behavior @bcmills described above. go get github.com/foo/bar/pkg/baz@v1.0.0 or go get github.com/foo/bar/pkg/baz will work as expected.

go get github.com/foo/bar/pkg/baz@pkg/baz/v1.0.0 won’t due to this issue but not sure how often ppl want to fetch a module/package in that way.