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

Open
bcmills opened this issue Jan 18, 2019 · 2 comments

Comments

@bcmills
Copy link
Member

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)

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2019

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

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.