This is moving the goalposts. The original problem was that installing a library should not execute code from that library.
In most sane environments, like for example native languages, this is already the case. Downloading a .dll file and putting it in an appropriate directory won't, by itself, execute code in that library.
You may argue that the code will get executed at some point anyway, but that's besides the point. Sandboxing the build environment is a different problem than sandboxing the test/staging/production environment.
I think we both agree that "adding random obstacles that don't actually protect anything" is not a valid approach to security, but my mental model of the build step is "transformation of input data into output data", and while this step may produce a malicious output from malicious inputs, it should not do anything malicious itself. For example, "gcc source.c" should not execute arbitrary code by itself.
alt Hacker News
This is moving the goalposts. The original problem was that installing a library should not execute code from that library.
In most sane environments, like for example native languages, this is already the case. Downloading a .dll file and putting it in an appropriate directory won't, by itself, execute code in that library.
You may argue that the code will get executed at some point anyway, but that's besides the point. Sandboxing the build environment is a different problem than sandboxing the test/staging/production environment.
I think we both agree that "adding random obstacles that don't actually protect anything" is not a valid approach to security, but my mental model of the build step is "transformation of input data into output data", and while this step may produce a malicious output from malicious inputs, it should not do anything malicious itself. For example, "gcc source.c" should not execute arbitrary code by itself.