
Example presubmit failure (after manually, temporarily deleting parts of `//third_party/rust/chromium_crates_io/supply-chain/audits.toml`): ``` $ git cl presubmit --force Running Python 3 presubmit commit checks ... checking owners took a long time: 0.6s checking for commit objects in tree took a long time: 0.6s ** Presubmit Warnings: 1 ** //tools/crates/run_cargo_vet.py check vpython3 /usr/local/google/home/lukasza/src/chromium2/src/third_party/rust/../../tools/crates/run_cargo_vet.py check --locked --frozen --no-minimize-exemptions (0.30s) failed Vetting Failed! 2 unvetted dependencies: unicode-width:0.1.11 missing ["safe-to-run", "does-not-implement-crypto"] wycheproof:0.4.0 missing ["safe-to-run", "does-not-implement-crypto"] Running cargo -Zunstable-options -C /usr/local/google/home/lukasza/src/chromium2/src/tools/crates/../../third_party/rust/chromium_crates_io vet check --locked --frozen --no-minimize-exemptions --cargo-arg=-Zbindeps --no-registry-suggestions Failed. Presubmit checks took 5.3s to calculate. There were Python 3 presubmit warnings. ``` Bug: 326234536 Change-Id: I09040d6dce8900b43a7002cad11439572432feae Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5388131 Reviewed-by: danakj <danakj@chromium.org> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Cr-Commit-Position: refs/heads/main@{#1277673}
2.9 KiB
unsafe
Rust Guidelines
Code Review Policy
All unsafe
Rust code in Chromium needs to be reviewed and LGTM-ed by a member
of the unsafe-rust-in-chrome@google.com
group and the review must be cc'd to
the group for visibility. This policy applies to both third-party code
(e.g. under //third_party/rust
) and first-party code.
To facilitate a code review please:
-
Add
unsafe-rust-in-chrome@google.com
to the CC line of a Gerrit code review.- TODO(https://crbug.com/328789397): Automate this via Tricium or AyeAye.
-
For each new or modified
unsafe
block, function,impl
, etc., add an unresolved "TODO:unsafe
review" comment in Gerrit.- TODO(https://crbug.com/328789397): Automate this via Tricium or AyeAye.
Note that changes anywhere in a crate that uses unsafe
blocks may violate
the internal invariants on which those unsafe
blocks rely. It is unrealistic
to require a unsafe-rust-in-chrome@google.com
review to re-audit all the
unsafe
blocks each time a crate is updated, but the crate OWNERS
and other
reviewers should be on the lookout for code changes which feel as though they
could affect invariants on which unsafe
blocks rely.
cargo vet
Policy
All third-party Rust code in Chromium needs to be covered by cargo vet
audits.
In other words, tools/crates/run_cargo_vet.py check
should always succeed.
Audit criteria required for a given crate depend on how the crate is used. The
criteria are written to
third_party/rust/chromium_crates_io/supply-chain/config.toml
by
tools/crates/run_gnrt.py vendor
based on whether
third_party/rust/chromium_crates_io/gnrt_config.toml
declares that the crate
is meant to be used (maybe transitively) in a safe
, sandbox
, or test
environment. For example, to declare that a crate is safe
to be used in the
browser process, it needs to be audited and certified to be safe-to-deploy
,
ub-risk-2
or lower, and either does-not-implement-crypto
or crypto-safe
.
Additional notes:
- Some audits can be done by any engineer ("ub-risk-0" and "safe-to-run") while
others will require specialists from the
unsafe-rust-in-chrome@google.com
group (see the "Code Review Policy" above. More details about audit criteria and the required expertise are explained in the auditing_standards.md. - See
Cargo Vet documentation
for how to record the audit in
audits.toml
. - Chromium uses both our own audits
(stored in
third_party/rust/chromium_crates_io/supply-chain/audits.toml
) as well as audits imported from other parts of Google (e.g. Android, Fuchsia, etc.). This means that adding a new crate does not necessarily require a new audit if the crate has already been audited by other projects.