cmd/go: use version control to discover the main module's version?
bcmills opened this issue · 5 comments
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:
- 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
gocommand vulnerabilities, so we would really like to avoid issuing VCS commands except when they are absolutely necessary. - 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.
- 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)
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.
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.
There is a related proposal under discussion at #37475.