{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigopknauhdywqwx4jerp25aokxzo6n2ijuny7iwfudk3ohkyslopy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mj6ftqo3iml2"
  },
  "path": "/t/build-security/24166#post_6",
  "publishedAt": "2026-04-10T22:41:43.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "Fwiw I thought about this personally a lot and while I appreciate the need for a more secure build system I just don't think it's worth the added complexity right now;\n\nIn almost any case if a library is included even if they aren't proc macro and do not use a build.rs their code gets run only a few seconds after the compile anyways when the developer is testing the code; this even works without calling it directly using crates like ctor.\n\nIn my mind the only way to get around this is to move to a fully sandboxed model throughout the entire chain from building but to executing as well. For that to work, in my opinion the only proper (or easy for that matter) way to do that right now is by compiling the code from proc macros and build.rs but the users code as well to wasm (with e.g. wasi) and run that in a sandbox, but I don't think that is something I would like to see being baked into cargo at this point in time. But what I would find interesting is the ability to somehow hook compilation (for compilation it might even be enough to just be able to specify a different target triple) and execution of build.rs and proc macros to allow experimentation with this through external tools, and then at a later point allow some kind of generic per crate permission system in crates.io, for example something like this:\n\n\n    [permissions.macro.sqlx]\n    network-access = { action = \"permit\", routes = [\"127.0.0.1:5432\"] }\n    filesystem-access = { action = \"permit\", paths = [\"mydb.sqlite\"] }\n\n    [permissions.build.rust_version]\n\n    [permissions.run]\n\n\n\nWhere the permission values and keys are sandbox implementation defined for now, until a concrete implementation has been fleshed out. But for now this wouldn't even need support from cargo's side and could just be done through the metadata system.\n\nAt a later point in time this experiment could then go three routes in my mind:\n\n  1. Decide it wasn't worth the additional complexity\n  2. Decide a singular implementation has been fleshed out and accept that into rust directly\n  3. add some kind of `[sandbox]` config section that can be used to specify a concrete sandbox implementation (crate) and then be used to enable / disable build.rs, proc_macro and run sandboxing, and/or be able to override it for individual crates.\n\n\n\nLet me know what you think about my suggestions\n\nThanks for reading Justus",
  "title": "Build Security"
}