# Hidden unsafe due to unintentionally abusable macros and include

**URL:** <https://internals.rust-lang.org/t/hidden-unsafe-due-to-unintentionally-abusable-macros-and-include/14107>\
**Category:** Unsafe Code Guidelines\
**Created:** [February 23, 2021, 5:40pm UTC](https://internals.rust-lang.org/t/hidden-unsafe-due-to-unintentionally-abusable-macros-and-include/14107 "2021-02-23T17:40:49Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [February 24, 2021, 3:21pm UTC](https://internals.rust-lang.org/t/hidden-unsafe-due-to-unintentionally-abusable-macros-and-include/14107/13 "2021-02-24T15:21:29Z")

</div>

You _can't_ rely on the `unsafe` keyword to check safety of crates. There are many other "safe" ways to inject arbitrary code and evade the checks:

> [@About supply-chain attacks](https://internals.rust-lang.org/t/about-supply-chain-attacks/14038/6):
>
> Regarding forbidding unsafe, I think it's commonly overestimated how much it would help, and underestimated how difficult it is to implement and how damaging it would be to the ecosystem. Rust would have to create a new, much bigger concept of "unsafe", because: std::process::Command is safe #[no\_mangle] is safe #[link\_section] is safe #[export\_name] is safe #[link(…)] extern "C" {} is safe println!("cargo:rustc-link-lib=native=…") is safe proc-macros are safe, and turing-complete, and …

This is because `unsafe` is not a security boundary. It's a lint for double-checking programmer's own assumptions, and not a sandbox.

---

_[View the full topic](https://internals.rust-lang.org/t/hidden-unsafe-due-to-unintentionally-abusable-macros-and-include/14107)._