3 ms·

Sandboxing just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you bui

Sandboxing just build.rs would only be be a minor inconvenience for the attacker, nothing more. The attacker can always as easily compromise the binary you build and as soon as you run it (e.g. in a test) you are owned. It would be a big pain for many that are in the unfortunate position to really need build scripts, though.

insanitybit 2mo ago
It would be more than a minor inconvenience. I can handle sandboxing my tests and production infra, but I can't handle sandboxing build scripts because I don't own that code in any sense.
Aurornis 2mo ago
I imagine it would be sandboxed by default with an escape hatch to run build scripts outside of the sandbox with user verification. It makes people stop and think about what’s happening. Not perfect, but it does help. When working on JS ecosystem projects I manually approve build scripts and spend some time researching dependencies with build scripts to see if I can avoid running the build script. Some people will ignore it and run everything, but it’s a huge step in the right direction to make it operator-decided.
kibwen 2mo ago
At the very least, it wouldn't be overly onerous when adding a dependency that requires a build script to require an opt-in via Cargo.toml, e.g. `build-script = true`. You'd make it viral so that any transitive dependency that requires a build script would affect its parent, then add the key as defaulting to `true` so as to not break backwards-compatibility, then switch the default to be more restrictive over a new edition. (This same key could be used to prevent proc-macros from having arbitrary system access as well, where by default proc macros could be compiled to WASM and run in a WASM sandbox and treated as pure functions.)
klabb3 2mo ago
100% agree. Wow I can’t believe how many think sandbox builds is an actually good idea, on a per language basis too. There are completely standard QoL issues in cargo that have been open for years and nobody is working on. Maintaining a sandbox for idk 3 operating systems minimum that have virtually no sandboxing support? For extremely diverse workloads that typically invoke commands? I mean.. good luck. There are still elephants (or rather mammoths) in the room for supply chain security, such as having 1500 nested deps for a standard project. It’s like we never woke up from the nightmare of leftpad. If your project had code from 100s of individuals, new versions can be pushed instantly, and nobody wants to review the code, then you have a time bomb. And also other problems.

insanitybit 2mo ago

It would be more than a minor inconvenience. I can handle sandboxing my tests and production infra, but I can't handle sandboxing build scripts because I don't own that code in any sense.

Aurornis 2mo ago

I imagine it would be sandboxed by default with an escape hatch to run build scripts outside of the sandbox with user verification. It makes people stop and think about what’s happening. Not perfect, but it does help. When working on JS ecosystem projects I manually approve build scripts and spend some time researching dependencies with build scripts to see if I can avoid running the build script. Some people will ignore it and run everything, but it’s a huge step in the right direction to make it operator-decided.

kibwen 2mo ago

At the very least, it wouldn't be overly onerous when adding a dependency that requires a build script to require an opt-in via Cargo.toml, e.g. `build-script = true`. You'd make it viral so that any transitive dependency that requires a build script would affect its parent, then add the key as defaulting to `true` so as to not break backwards-compatibility, then switch the default to be more restrictive over a new edition. (This same key could be used to prevent proc-macros from having arbitrary system access as well, where by default proc macros could be compiled to WASM and run in a WASM sandbox and treated as pure functions.)

klabb3 2mo ago

100% agree. Wow I can’t believe how many think sandbox builds is an actually good idea, on a per language basis too. There are completely standard QoL issues in cargo that have been open for years and nobody is working on. Maintaining a sandbox for idk 3 operating systems minimum that have virtually no sandboxing support? For extremely diverse workloads that typically invoke commands? I mean.. good luck. There are still elephants (or rather mammoths) in the room for supply chain security, such as having 1500 nested deps for a standard project. It’s like we never woke up from the nightmare of leftpad. If your project had code from 100s of individuals, new versions can be pushed instantly, and nobody wants to review the code, then you have a time bomb. And also other problems.