{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreid33rcwdopngbmlewtra4odx6seybnbdrfjk7ctpwruqtiaqms7uu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mj5ygfwxxzn2"
  },
  "path": "/t/build-security/24166#post_1",
  "publishedAt": "2026-04-10T18:14:42.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Rust builds have two Trojan features. Here are thoughts about reigning them in:\n\n### 1. Build.rs\n\nI recall that there was a discussion long ago that the most common tasks could be implemented centrally and activated by configuration. In many crates this would be enough: only a `build.toml` instead of an omnipotent (hence potentially dangerous) `build.rs`. This sounded good, but I haven’t heard news for a long time.\n\nIndependently of where this stands, I would add a `Cargo.toml` property allowing `build.rs`. Cargo new/init would start adding it with an empty list to push adoption:\n\n\n    build-rs-allowed = [\"crate1\", \"crate2\"]\n\n\nIf this property is present (and as of edition 2027 even if not present) a dependency (even indirect) with a `build.rs` would cause a build error, unless it is in the list.\n\n### 2. Proc Macros\n\nMost macros have no business snooping around the file system, or even modifying it, or calling home. I guess this is equivalent to saying: proc macros should be restricted to `core` and `alloc`. Only a few, like sqlx (I suppose sqlx-macros concretely), need `std`.\n\nI would add a `Cargo.toml` property allowing `std`. Cargo new/init would start adding it with an empty list to push adoption:\n\n\n    macro-may-use-std = [\"sqlx-macros\"]\n\n\nIf this property is present (and as of edition 2027 even if not present) a proc macro dependency (even indirect) must be `no-std`, unless it is in the list.",
  "title": "Build Security"
}