| This crate will not introduce a serious security vulnerability to production |
| software exposed to untrusted input. |
| |
| Auditors are not required to perform a full logic review of the entire crate. |
| Rather, they must review enough to fully reason about the behavior of all unsafe |
| blocks and usage of powerful imports. For any reasonable usage of the crate in |
| real-world software, an attacker must not be able to manipulate the runtime |
| behavior of these sections in an exploitable or surprising way. |
| |
| Ideally, all unsafe code is fully sound, and ambient capabilities (e.g. |
| filesystem access) are hardened against manipulation and consistent with the |
| advertised behavior of the crate. However, some discretion is permitted. In such |
| cases, the nature of the discretion should be recorded in the `notes` field of |
| the audit record. |
| |
| For crates which generate deployed code (e.g. build dependencies or procedural |
| macros), reasonable usage of the crate should output code which meets the above |
| criteria. |
