4 ms·

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

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_module_and_install_them https://pkg.go.dev/cmd/go#hdr-Add_dependencies_to_current_mo...

TheDong 1y ago
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-2095 https://pkg.go.dev/vuln/GO-2023-1842 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 1y ago
  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 1y ago
    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 1y ago
      > 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 1y ago
I don't really get what you're trying to say, go get does not execute arbitrary code.

TheDong 1y ago

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-2095 https://pkg.go.dev/vuln/GO-2023-1842 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 1y ago
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 1y ago
  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 1y ago
    > 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 1y ago

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