{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie3ymwy7xlwzjej433xqh22sug4m2nfe2vllqw2a6tkkbtrjhajzi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mj6tcb2dnpk2"
  },
  "path": "/t/build-security/24166#post_4",
  "publishedAt": "2026-04-10T19:43:35.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "robofinch:\n\n> Malware doesn’t need to be future-proof, and if a proc-macro is compiled to the host’s target (presumably capable of running some form of not-sandboxed assembly), it could conceivably find a way to execute whatever assembly it wants via UB\n\nIt wouldn't even really have to be UB, just some form of system-specific transmute (which is possible even in safe Rust by exploiting type-system soundness bugs – it isn't _supposed_ to be but there are numerous ways to do it in practice). Operating systems are gradually starting to move away from the model of \"any read-only part of the executable image can be executed\", but there are still lots of computers around which do have that rule, so on such computers a program would just need to create a constant static array of bytes that represented the code it wanted to run, then `transmute` a reference to it (either using unsafe code or using a type-system soundness hole) into a `fn` and call it. This sort of transmute isn't obviously even undefined behavior (although it is highly system-specific).\n\nIn general, Rust's security model is not designed to defend against malicious code given as input to the compiler (as opposed to malicious input given to a program at runtime) and thus any sort of build-time sandboxing has to be outside the Rust language itself.",
  "title": "Build Security"
}