You're confusing compile-time with build-time. And build time code execution exists absolutely exists in go, because that's what a build tool is. https://pkg.go.dev/cmd/go#hdr-Add_dependencies_to_current_mo...

▲

TheDong 5 days ago | parent | next [-]

I think you're misunderstanding.

"go build" of arbitrary attacker controlled go code will not lead to arbitrary code execution.

If you do "git clone attacker-repo && cargo build", that executes "build.rs" which can exec any command.

If you do "git clone attacker-repo && go build", that will not execute any attacker controlled commands, and if it does it'll get a CVE.

You can see this by the following CVEs:

https://pkg.go.dev/vuln/GO-2023-2095

https://pkg.go.dev/vuln/GO-2023-1842

In cargo, "cargo build" running arbitrary code is working as intended. In go, both "go get" and "go build" running arbitrary code is considered a CVE.

▲

thayne 5 days ago | parent [-]

But `go generate` can, and that is required to build some go projects.

It is also somewhat common for some complicated projects to require running a Makefile or similar in order to build, because of dependencies on things other than go code.

▲

TheDong 5 days ago | parent [-]

The culture around "go generate" is that you check in any files it generates that are needed to build.

In fact, for go libraries you effectively have to otherwise `go get` wouldn't work correctly (since there's no way to easily run `go generate` for a third-party library now that we're using go modules, not gopath).

Have you actually seen this in the wild for any library you might `go get`? Can you link any examples?

	▲	thayne 5 days ago \| parent [-]
		> Have you actually seen this in the wild for any library you might `go get`? Not for a library, but I have for an executable. Unfortunately, I don't remember what it was.

▲

cedws 5 days ago | parent | prev [-]

I don't really get what you're trying to say, go get does not execute arbitrary code.