debug/buildinfo/testdata: test binaries should be more reproducible #71734
Comments
seankhliao
changed the title
src/debug/buildinfo/testdata/ binaries included in the go 1.24 release easier to reproduce/verify
|
CC @prattmic |
|
Sure, I probably should have checked in the source file and used -trimpath. I can do that. To be clear, any Go 1.17 binary is sufficient for this test, it doesn't need to be a perfect reproduction. The notgo one is trickier, as reproducible C binaries are trickier. Maybe it would be more straightforward to use some binary very likely to exist on the system (e.g., /bin/ls). Though that is likely bad for debugging failures, if any occur, as CI vs local versions of /bin/ls will differ. |
|
In https://go.dev/cl/651175 I checked in the source files plus more explicit instructions. This should make it easy to reproduce the Go binary. The C binary is likely still difficult to reproduce, as you'll need to get exactly the correct gcc version (and libc?), but I'm not sure it is worth more effort. |
|
Change https://go.dev/cl/651175 mentions this issue: |
Overzealous security scanners don't like the Go 1.17 binary because they think it has every 1.17 security vulnerability. base64-encode the binary to hide from them. I've also extended the instructions to make the binary easier to reproduce. Since we do the Go binary, we might as well do the C binary too, as it apparently makes some virus scanners unhappy. Fixes #71753. For #71734. For #71821. Change-Id: I6a6a636cccbf5312522f52f27f74eded64048fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/651175 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
|
Change https://go.dev/cl/651235 mentions this issue: |
seankhliao
added
the
NeedsFix
Overzealous security scanners don't like the Go 1.17 binary because they think it has every 1.17 security vulnerability. base64-encode the binary to hide from them. I've also extended the instructions to make the binary easier to reproduce. Since we do the Go binary, we might as well do the C binary too, as it apparently makes some virus scanners unhappy. Fixes #71858. For #71753. For #71734. For #71821. Change-Id: I6a6a636cccbf5312522f52f27f74eded64048fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/651175 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit af00524) Reviewed-on: https://go-review.googlesource.com/c/go/+/651235
The binaries added in 28aed40 and part of the go 1.24.0 release artifacts are not reproducible without knowing the
GOPATH(/usr/local/google/home/mpratt/go) and source path (/tmp/old/main.go) that were used to build them. And even that isn't enough, you have to also know thatmain.gowas formatted withgofmt. Can the source files and more accurate build instructions used to generate them be more than a comment and instead be separate files that could be used to verify that the provided binary is an accurate representation of its source?This is not enough to generate the given
go117binary:This is what it takes to reproduce it:
And the abbreviated output:
For easier verification, can
go117also be built with-trimpath?The above is mostly about reproducing the
go117binary, but thenotgoC binary should be reproducible as well.attempted `notgo` reproduction
The text was updated successfully, but these errors were encountered: