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: use version control to discover the main module's version? #29814

Closed
bcmills opened this issue Jan 18, 2019 · 5 comments
Closed

cmd/go: use version control to discover the main module's version? #29814

bcmills opened this issue Jan 18, 2019 · 5 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Milestone

Comments

@bcmills
Copy link
Contributor

bcmills commented Jan 18, 2019

This is a follow-on to #26404 and #29228.

When a binary is build from within a module's source tree, the output from runtime/debug.ReadBuildInfo currently reports that module as having version (devel).

If the source tree is a pristine checkout from a version-control system — or is within the (read-only) module cache — we could instead interrogate the version-control system to find the corresponding version or pseudo-version to embed.

However, that has a couple of caveats:

  1. It would require us to run VCS commands within the user's source tree. Historically, running VCS commands has been a source of entirely too many go command vulnerabilities, so we would really like to avoid issuing VCS commands except when they are absolutely necessary.
  2. Given a commit, we can produce a pseudo-version for that commit, but we can't tell whether that commit has been published to the origin. It would be nice to preserve the invariant that only published versions are advertised in debug info, but that may incur an extra network fetch.
  3. Within a module, we apply that module's replacements and exclusions, and the user's VCS checkout may also have applied some transformations. (devel) currently provides a clue that those module-specific changes are in effect: if we were to indicate an explicit version instead, we would need to provide some way to indicate that replacements and exclusions were applied.

(CC @jayconrod @rsc @hyangah)

@bcmills bcmills added Proposal NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Jan 18, 2019
@jayconrod
Copy link
Contributor

This would be valuable to users, but we should be really careful, and we should leverage our module verification infrastructure as much as we can.

I wonder if how far we can get just with go get example.com/foo/cmd/bar@v1.2.3? Everything would be built from verified modules, and nothing would come from a local module. For binaries built within a local workspace, I think the local module should always be marked (devel), as well as any local replacements, regardless of what VCS tools say.

I'm not sure what the threat model is exactly, but I'd be worried about people trusting these stamps for authenticating binaries. A malicious user could rig up local VCS tools to tell cmd/go a module is pristine or is checked out from a certain tag when it really isn't.

@mvdan
Copy link
Member

mvdan commented Jan 19, 2019

I wonder if how far we can get just with go get example.com/foo/cmd/bar@v1.2.3?

If that worked reliably, I agree that most end users should use that instead of git clone and go install. Though it would be nice if the two methods produced the same result.

bradfitz added a commit to tailscale/tailscale that referenced this issue Feb 28, 2020
Maybe we'll auto-bump this with a bot over time.

See golang/go#37475 & golang/go#29814

Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
@FiloSottile
Copy link
Contributor

There is a related proposal under discussion at #37475.

@bcmills
Copy link
Contributor Author

bcmills commented Jun 24, 2020

Proposal #37475 is approved, so closing this as a duplicate.

@bcmills
Copy link
Contributor Author

bcmills commented Jun 24, 2020

Duplicate of #37475

@bcmills bcmills marked this as a duplicate of #37475 Jun 24, 2020
@bcmills bcmills closed this as completed Jun 24, 2020
@golang golang locked and limited conversation to collaborators Jun 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Projects
None yet
Development

No branches or pull requests

5 participants