Description
Background
Proposal #37475 suggests adding a version of git checkout from which the binary is built to the binary itself.
Comments #37475 (comment) and #37475 (comment) describe a workflow which will be broken by this change, as it relies on binaries' checksum stability.
This stability is already slightly compromised, as versions of dependencies are embedded in the final binary. However, it works pretty well in practice: when a dependency changes, it usually brings new code, because nobody is updating dependencies constantly, only to get a new feature or a bugfix.
OTOH, when a checkout version changes, often it does not bring new code, especially for monorepo. As an anecdotic data point, the project I'm working in regularly sees binaries staying stable over hundreds of revisions of source code. #37475 would increase the number of produced Docker images 100x and force upgrades of all components needlessly (unless a scheme equivalent to removing version information from binaries is employed).
Proposal
This proposal suggests adding a flag that will disable embedding version information completely (including the version of Go).
This will solve the dependencies-induced checksum stability compromise as well.
Practical considerations
I'd like to ask to make sure #37475 and this proposal are considered together, to avoid releasing a version of Go where the workflow described in that proposal is broken.
Activity
bcmills commentedon Mar 5, 2020
CC @jayconrod @matloob
mark-rushakoff commentedon Mar 5, 2020
As for the build process I mentioned in #37475 (comment), we are using
GOFLAGS='-mod=vendor -ldflags=-buildid='
. We also are explicitly not using-trimpath
as that includes module version info that we don't want for these builds.A single flag we could use that was something like
-deterministic-build
or-reproducible-build
or-omit-version-embedding
would make things much simpler for our build process, if we could rely on that flag to be stable across versions of Go.ianlancetaylor commentedon Mar 5, 2020
Let's please discuss this on #37475. I can't see any reason to make this a separate issue. Thanks.
bcmills commentedon Mar 6, 2020
@ianlancetaylor, I would prefer to keep this as a separate issue. Given that we already do embed some version information, we can consider whether to add a flag to omit that information separately from whether we expand that information.
(#37475 is about expanding the existing version information, and this issue is about redacting it.)
rsc commentedon Jul 15, 2021
Module version information is going to become more and more critical to Go programs, as it is exposed in APIs like runtime/debug.BuildInfo and will be consumed by vulnerability checks and other supply chain security issues. It is also very small compared to the rest of the binary. I don't believe it makes much sense at all to provide a flag to strip that information from the binaries.
I do see the point of having a flag to stop embedding VCS info into the binary. If and when we implement that feature, I think we can easily commit to being able to turn it off.
[-]proposal: cmd/go: add a flag to stop embedding versioning information into the binaries[/-][+]proposal: cmd/go: add a flag to stop embedding VCS information into the binaries[/+]dottedmag commentedon Jul 15, 2021
Module version information is not problematic. Retitled to clarify.
rsc commentedon Jul 15, 2021
Thanks. I added a note about remembering the flag in #37475
and we will mark this proposal as retracted care of at the next proposal reviewand I am closing this proposal as accepted/taken care of.