I suppose that go's go:generate workflow can also be abused to land a worm like the ones spreading via npm, as you can build programs that just scrape the whole hard drive for git projects and patch the go.mod dependencies there, and you could also just write this in go as a toolchain script, for example.

NPM's achilles is the pre/postinstall step which can run arbitrary commands and shell scripts without the user having any way to intervene.

Dependencies must be run in isolated chroot sandboxes or better, inside containers. That would be the only way to mitigate this problem, as the filesystem of the operating system must be separated from the filesystem of the development workflow.

On top of that most host based firewalls are per-binary instead of per-cmdline. That leads to the warnings and rules relying on that e.g. "python" or "nodejs" getting network access allowlisted, instead of say "nodejs myworm.js". So firewalls in general are pretty useless against this type of malware.

▲

yegle an hour ago | parent | next [-]

`go:generate` is for the package provider, the command never runs when someone `go install` or `go get` the package.

	▲	cookiengineer an hour ago \| parent [-]
		Note that the NPM worms are spreading because the package providers are developing on their libraries without them noticing a malicious dependency. It is not users/consumers spreading the worm, it is developers spreading it. Your mismatch is that you think in policies, not assessments here. Nothing in my normal go workflow will ask me if I want to run "curl download whatever from the internet" when I run go build. Though I agree with the difference in workflow, there is not a single mechanism in go catching this. go.mod files can be just patched by the worm, and/or hidden behind a /v123 folder or whatever to play shenanigans on API differences.

▲

xena an hour ago | parent | prev [-]

go:generate is done at dev time, not at build time.

	▲	cookiengineer an hour ago \| parent [-]
		Actually bindings are usually generated like that, at build time (though with a build cache that nobody knows how it corrupts all the time). Examples that come to mind: webview/webview, webkit, cilium/ebpf and most other CGo projects that I have seen.