Arbitrary code execution during compilation – rust

Afaik you don’t even need to use macros for this, can’t you just put a build.rs file in the crate and it will execute on build?<p>Almost all build&#x2F;project systems I know have this functionality simply because execution of arbitrary programs is too useful to go without. Any C# project (.csproj) for example can include a task that eats your homework.<p>It’s scary but I don’t see a solution like sandboxing being very easy to retrofit either.

Nothing new to see here...<p>Any of these steps could do the same to your system, and it&#x27;s been the &quot;standard&quot; for 30+ years:<p><pre><code> .&#x2F;configure make sudo make install </code></pre> Or literally any other language&#x2F;package manager that supports build scripts.

I would expect any sufficiently powerful macro system would have to be this way.<p>Don&#x27;t most editors ask you whether or not you want to trust some code before opening it with full privileges anyway?

So... if I&#x27;m using a third party crate, I&#x27;m already trusting it not to do bad things in my running application. Why is it such a big deal that it could do bad things during build time just before I run it? If I&#x27;m using a third party crate... I&#x27;ve got to trust it one way or the other. So what&#x27;s the big deal here?

Old, it&#x27;s not new that macro expansions, build files and build tooling can do that. (And if we sandboxed that, you still get infected release builds, check your deps..)<p>See NPM installations and &quot;please sponsor this project&quot; messages, which can also give you a virus.

We must start systematically sandboxing developer tools. It&#x27;s scary how sensitive dev workspaces are, and how much random crap we run. After decades of training the world&#x27;s parents and grandparents not to download and run programs from untrusted sources we now routinely do it ourselves.

D does this &quot;the right way&quot;, which is to say free of side-effects.<p><a href="https:&#x2F;&#x2F;tour.dlang.org&#x2F;tour&#x2F;en&#x2F;gems&#x2F;compile-time-function-evaluation-ctfe" rel="nofollow">https:&#x2F;&#x2F;tour.dlang.org&#x2F;tour&#x2F;en&#x2F;gems&#x2F;compile-time-function-ev...</a><p><a href="https:&#x2F;&#x2F;wiki.dlang.org&#x2F;Compile-time_vs._compile-time" rel="nofollow">https:&#x2F;&#x2F;wiki.dlang.org&#x2F;Compile-time_vs._compile-time</a><p>You&#x27;re supposed to be able to trust the compiler, you can&#x27;t trust people. (<a href="https:&#x2F;&#x2F;forum.dlang.org&#x2F;post&#x2F;po2734$20mq$1@digitalmars.com" rel="nofollow">https:&#x2F;&#x2F;forum.dlang.org&#x2F;post&#x2F;po2734$20mq$1@digitalmars.com</a>)

I think this is actually a good case for development containers. That way you&#x27;re very explicit in what you expose in the container.<p>It could still read your AWS keys that you pass in through the ENV though and upload those to some server in China &#x2F; Russia.<p>Or it could delete all your source code, but that&#x27;s counter productive.

This is a feature, not a bug: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;MWRPYBoCEaY" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;MWRPYBoCEaY</a>

Isn&#x27;t that one of the main selling points of Jai?

POC to demonstrate how to delete files when cargo build runs

I filed a issue on `rust-analyzer` and apparently it is by design - <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust-analyzer&#x2F;issues&#x2F;14375">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust-analyzer&#x2F;issues&#x2F;14375</a>

Such a safe language, better than everything else so much so that what amounts to a linter does compiles