Filippo Valsorda is a user on mastodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Trying to reproduce the release build of a popular Go software. There are Makefiles and it's pretty basic, but coming up with slight differences. Taking bets:

1/10 Backdoor
3/5 Filippo is stupid
3/10 Owner messed up

Three hours in. I know much more about embedded GOROOT paths.

Interestingly, the compiler will patch the paths of the symbols in the stdlib to match the GOROOT. That's smart, avoids recompiling the stdlib at every GOROOT change, but allows debuggers to find the stdlib files.

Also, should make reproducible builds just work.

So it's not this.

But! Go binaries also get the *default* GOROOT copied in. The one that the compiler will use if no GOROOT is set, which was set at (compiler) compile time. Binaries need to know it to behave exactly like the compiler that built them.

So this is a fixed diff. But I don't see how it would affect the build ID.

Interesting read: github.com/golang/go/issues/17

Filippo Valsorda @filippo

Figured it out! ๐Ÿ™Œ And got it to reproduce ๐Ÿ’ฅ

The default GOROOT matters to the build ID because it's written to zversion.go, which is intentionally hashed in to detect toolchain changes.

Not, as I thought, because of the filepaths in the stdlib build IDs. The tree is recomputed with the current GOROOT instead. So every time you change GOROOT, the stdlib *is* rebuilt. (My previous tweet was wrong!)

All bets are off, it's Filippo is stupid.

ยท Amaroq ยท 0 ยท 2

@filippo I fav'd this for the bookmark and to signal nice debugging, not bc you're stupid. ๐Ÿ‘

@kennwhite Of course ๐Ÿ˜Š โค

FYI, your fav might have gotten lost in the 500 our instance is suffering right now, because it doesn't show up on my side.