3 ms·

Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specifi

Why does every build have the ability to run arbitrary code by default in the first place? That seems like something you should opt into only under very specific scenarios and even then it should probably be built around a WASM sandbox or microVM (as the parent suggested).

bluGill 1mo ago
Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work. This is partially because for nearly every project the build system is something they need and don't care about. When they need something weird they hack just enough to make it work and never ask "how should the build system change so that this was a property instead of running code", and thus build systems are slow to improve. In a number of cases the build system did have a way to do that thing, but the person didn't know about it. There are also a lot of code generators out there. I have yet to see a large project which didn't have their own code generator for something specific to their project (protobuf is an example from Google that has escaped and become useful elsewhere, but there are many others that are specific to one project. Yacc is from the 1970s, and stands for "yet another compiler compiler" - implying the idea was already common 50 years ago). You cannot have/use these useful tools without running arbitrary code.
- skydhash 1mo ago
  I don't mind code execution as even make has shell scripting embedded, same thing with meson. My issue is with network access to download random stuff without it being declared somewhere and signed. I'm using OpenBSD and the ports system set up two users `_pbuild` and `_pfetch` for building packages. The first one is for building and the sample `pf.conf` (firewall) forbid it from accessing the network. The second does fetch the files , but it's declarative with every files listed and signed. Even for languages like go and rust. Fetching files while building is the bad idea there.
  - bluGill 1mo ago
    Good point. Many build systems also want to be a package manager, but the two are and should be separate. If you have a simple problem it makes things easy to combine them into one. However they need to be separate anyway, both for security and also to make other weird situations easier.
- throwaway894345 1mo ago
  I mean, I understand the need for an escape hatch, but it’s strange to me that it’s the default and that it’s unsandboxed. Feels like build scripts should be treated like CGo in Go—a rare escape hatch that people strongly try to avoid so that downstream builds are better. To that end, Go doesn’t even have macros or code generation and it gets by reasonably well without any build scripts should support—I understand that Rust’s emphasis on systems programming probably drives more scenarios where build scripts are genuinely necessary, but I strongly suspect that, as with C and C++, making it easy for people to do weird stuff probably drives a lot of people to think they need to do weird stuff.
  - bluGill 1mo ago
    Until a few years ago abuse of the escape hatch was seen as something theoretically possible but not realistic. Sadly attackers have abused trust and so even though most people are honest we can no longer trust anybody.
kibwen 1mo ago
> Why does every build have the ability to run arbitrary code by default in the first place? Nearly every time that you see a build script in use it's to support building C code, which has no standard build process and which often involves executing shell commands, and the shell itself is an arbitrary code execution environment with arbitrary access to the network.

bluGill 1mo ago

Because many many builds end up doing something just a little weird that the build system cannot handle by default. Ideally the build system would be fully property/dependency based and so it wouldn't have to run arbitrary code. In the real world everybody has something weird about their build that the build system cannot make work. This is partially because for nearly every project the build system is something they need and don't care about. When they need something weird they hack just enough to make it work and never ask "how should the build system change so that this was a property instead of running code", and thus build systems are slow to improve. In a number of cases the build system did have a way to do that thing, but the person didn't know about it. There are also a lot of code generators out there. I have yet to see a large project which didn't have their own code generator for something specific to their project (protobuf is an example from Google that has escaped and become useful elsewhere, but there are many others that are specific to one project. Yacc is from the 1970s, and stands for "yet another compiler compiler" - implying the idea was already common 50 years ago). You cannot have/use these useful tools without running arbitrary code.

skydhash 1mo ago
I don't mind code execution as even make has shell scripting embedded, same thing with meson. My issue is with network access to download random stuff without it being declared somewhere and signed. I'm using OpenBSD and the ports system set up two users `_pbuild` and `_pfetch` for building packages. The first one is for building and the sample `pf.conf` (firewall) forbid it from accessing the network. The second does fetch the files , but it's declarative with every files listed and signed. Even for languages like go and rust. Fetching files while building is the bad idea there.
- bluGill 1mo ago
  Good point. Many build systems also want to be a package manager, but the two are and should be separate. If you have a simple problem it makes things easy to combine them into one. However they need to be separate anyway, both for security and also to make other weird situations easier.
throwaway894345 1mo ago
I mean, I understand the need for an escape hatch, but it’s strange to me that it’s the default and that it’s unsandboxed. Feels like build scripts should be treated like CGo in Go—a rare escape hatch that people strongly try to avoid so that downstream builds are better. To that end, Go doesn’t even have macros or code generation and it gets by reasonably well without any build scripts should support—I understand that Rust’s emphasis on systems programming probably drives more scenarios where build scripts are genuinely necessary, but I strongly suspect that, as with C and C++, making it easy for people to do weird stuff probably drives a lot of people to think they need to do weird stuff.
- bluGill 1mo ago
  Until a few years ago abuse of the escape hatch was seen as something theoretically possible but not realistic. Sadly attackers have abused trust and so even though most people are honest we can no longer trust anybody.

kibwen 1mo ago

> Why does every build have the ability to run arbitrary code by default in the first place? Nearly every time that you see a build script in use it's to support building C code, which has no standard build process and which often involves executing shell commands, and the shell itself is an arbitrary code execution environment with arbitrary access to the network.