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: do not treat branches with semantic-version names as releases [1.16 backport] #50686

Closed
gopherbot opened this issue Jan 19, 2022 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge GoCommand cmd/go Security
Milestone

Comments

@gopherbot
Copy link

@FiloSottile requested issue #35671 to be considered for backport to the next 1.16 minor release.

@gopherbot please open backport issues. Materializing versions from branches might be unexpected and bypass ACLs that limit the creation of tags but not branches. It's also better for the version list to be consistent across supported Go versions.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Jan 19, 2022
@gopherbot gopherbot added this to the Go1.16.14 milestone Jan 19, 2022
@dmitshur dmitshur added the GoCommand cmd/go label Jan 25, 2022
@bcmills bcmills added the CherryPickApproved Used during the release process for point releases label Feb 3, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Feb 3, 2022
@bcmills bcmills self-assigned this Feb 3, 2022
@gopherbot
Copy link
Author

Change https://golang.org/cl/382839 mentions this issue: [release-branch.go1.16] cmd/go/internal/modfetch: do not short-circuit canonical versions

@gopherbot
Copy link
Author

Closed by merging de76489 to release-branch.go1.16.

gopherbot pushed a commit that referenced this issue Feb 7, 2022
…t canonical versions

Since at least CL 121857, the conversion logic in
(*modfetch).codeRepo.Stat has had a short-circuit to use the version
requested by the caller if it successfully resolves and is already
canonical.

However, we should not use that version if it refers to a branch
instead of a tag, because branches (unlike tags) usually do not refer
to a single, stable release: a branch named "v1.0.0" may be for the
development of the v1.0.0 release, or for the development of patches
based on v1.0.0, but only one commit (perhaps at the end of that
branch — but possibly not even written yet!) can be that specific
version.

We already have some logic to prefer tags that are semver-equivalent
to the version requested by the caller. That more general case
suffices for exact equality too — so we can eliminate the
special-case, fixing the bug and (happily!) also somewhat simplifying
the code.

Updates #35671
Fixes #50686
Fixes CVE-2022-23773

Change-Id: I2fd290190b8a99a580deec7e26d15659b58a50b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/378400
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit fa4d9b8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/382839
@rsc rsc unassigned bcmills Jun 22, 2022
@golang golang locked and limited conversation to collaborators Jun 22, 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 Security
Projects
None yet
Development

No branches or pull requests

3 participants