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/internal/modfetch: erroneously resolves a v2.…+incompatible version when a v2/go.mod file exists [1.16 backport] #51331

Closed
gopherbot opened this issue Feb 23, 2022 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge GoCommand cmd/go release-blocker
Milestone

Comments

@gopherbot
Copy link

@bcmills requested issue #51324 to be considered for backport to the next 1.16 minor release.

@gopherbot, please backport to Go 1.16 and Go 1.17. This is a regression introduced in a security release (for #35671), and can cause confusion if a Go user accidentally passes the wrong module path to go get.

@gopherbot
Copy link
Author

Change https://go.dev/cl/387923 mentions this issue: [release-branch.go1.16] cmd/go: avoid +incompatible major versions if a go.mod file exists in a subdirectory for that version

@bcmills bcmills added CherryPickApproved Used during the release process for point releases release-blocker and removed CherryPickCandidate Used during the release process for point releases labels Mar 2, 2022
@bcmills
Copy link
Contributor

bcmills commented Mar 2, 2022

Marking as release-blocker because this is addressing a regression introduced in a previous minor release.

@gopherbot
Copy link
Author

Closed by merging 02e5505 to release-branch.go1.16.

gopherbot pushed a commit that referenced this issue Mar 3, 2022
… a go.mod file exists in a subdirectory for that version

Previous versions of the 'go' command would reject a pseudo-version
passed to 'go get' if that pseudo-version had a mismatched major
version and lacked a "+incompatible" suffix. However, they would
erroneously accept a version *with* a "+incompatible" suffix even if
the repo contained a vN/go.mod file for the same major version, and
would generate a "+incompatible" pseudo-version or version if the user
requested a tag, branch, or commit hash.

This change uniformly rejects "vN.…" without "+incompatible", and also
avoids resolving to "vN.…+incompatible", when vN/go.mod exists.
To maintain compatibility with existing go.mod files, it still accepts
"vN.…+incompatible" if the version is requested explicitly as such
and the repo root lacks a go.mod file.

Fixes #51331
Updates #51324
Updates #36438

Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139
Reviewed-on: https://go-review.googlesource.com/c/go/+/387675
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
(cherry picked from commit 5a9fc94)
Reviewed-on: https://go-review.googlesource.com/c/go/+/387923
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@golang golang locked and limited conversation to collaborators Mar 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge GoCommand cmd/go release-blocker
Projects
None yet
Development

No branches or pull requests

3 participants