{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiblwqaheex4zfs36njnnnhgzianzjxsm5fmt22q5dbhxeh4bbxm7e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mj675ll4sr72"
  },
  "path": "/t/build-security/24166#post_2",
  "publishedAt": "2026-04-10T18:44:31.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "For the second idea, what about adding a `cfg` to `std` that causes its `fs` implementation to always panic, or something like that? I see this as similar to the `wasm32-unknown-unknown` target. Then, a `macro-may-use-fs` list could configure that `cfg`.\n\nThough, that approach would need to cover other problematic parts of `std` to be functional: `arch`, `fs` of course, `net`, `os`, `process`, ….\n\nAnd…. I just realized a critical flaw. I know const-eval happens in an interpreter that can catch UB, but what happens if a proc-macro has UB? 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, _at least for the current compiler version_ where the malware author can tweak the code until they see the optimizer doesn’t notice/take advantage of the UB.\n\nMacro sandboxing would need to happen at a lower level than `std`.",
  "title": "Build Security"
}