|
| 1 | +# Working with cargo vet |
| 2 | + |
| 3 | +## Introduction |
| 4 | + |
| 5 | +`cargo vet` is a tool to help ensure that third-party Rust dependencies have been audited by a trusted entity. |
| 6 | +It matches all dependencies against a set of audits conducted by the authors of the project or entities they trust. |
| 7 | +To learn more, visit [mozilla/cargo-vet](https://github.com/mozilla/cargo-vet) |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +## Adding a new dependency |
| 12 | + |
| 13 | +When updating or adding a new dependency, we need to ensure it's audited before being merged into main. |
| 14 | +For our repositories, we have designated experts who are responsible for vetting any new dependencies being added to their repository. |
| 15 | +_It is the shared responsibility of the developer creating the PR and the auditors to conduct a successful audit._ |
| 16 | +Follow the process below to ensure compliance: |
| 17 | + |
| 18 | +### For Developers |
| 19 | +1. **Respond to `cargo vet` failures**: |
| 20 | + - If your PR fails the `cargo vet` step, the cargo-vet workflow will add a comment to the PR with a template questionnaire |
| 21 | + - Copy the questionnaire, fill it out and paste it as a new comment on the PR. This greatly helps the auditors get some context of the changes requiring the new dependencies |
| 22 | + |
| 23 | +2. **Engage with auditors**: |
| 24 | + - Respond to any questions that the auditors might have regarding the need of any new dependencies |
| 25 | + |
| 26 | +3. **Rebase and verify**: |
| 27 | + - At their discretion, auditors will check in their audits into either [rust-crate-audits](https://github.com/OpenDevicePartnership/rust-crate-audits) or into the same repository |
| 28 | + - Once the new audits have been merged, rebase your branch on main and verify it passes `cargo vet` |
| 29 | + ```bash |
| 30 | + git fetch upstream |
| 31 | + git rebase upstream/main |
| 32 | + cargo vet |
| 33 | + ``` |
| 34 | + |
| 35 | +4. **Update PR**: |
| 36 | + - If the audits were checked into rust-crate-audits, they will show up in _imports.lock_ on running `cargo vet`. In this case add the updated _imports.lock_ to your PR |
| 37 | + - If the audits were checked into the same repository, they will be present in _audits.toml_ after rebase and you can simply force push to your PR after rebase |
| 38 | + ```bash |
| 39 | + git push -f |
| 40 | + ``` |
| 41 | + |
| 42 | +5. **Check PR status**: |
| 43 | + - The existing PR comment from the previous failure will be updated with a success message once the check passes |
| 44 | + |
| 45 | +### For Auditors |
| 46 | + |
| 47 | +1. **Review the questionnaire**: |
| 48 | + - Check the filled questionnaire on the PR once the developer responds to the `cargo vet` failure |
| 49 | + - Respond to the developer comment in case more information is needed |
| 50 | + |
| 51 | +2. **Audit new dependencies**: |
| 52 | + - Inspect the `cargo vet` failures using your preferred method |
| 53 | + - Use [gh pr checkout](https://cli.github.com/manual/gh_pr_checkout) to checkout the PR and run `cargo vet --locked` |
| 54 | + - Use [Github Pull Requests for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github) to checkout the PR and run `cargo vet --locked` |
| 55 | + - For more suggestions: [Checking out pull requests locally](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally) |
| 56 | + |
| 57 | +3. **Follow `cargo vet` recommendations**: |
| 58 | + - Follow the recommendations of the `cargo vet` command output, either `cargo vet diff` for version update or `cargo vet inspect` for new dependencies |
| 59 | + |
| 60 | +4. **Record audits**: |
| 61 | + - Use `cargo vet certify` to add new audits to _audits.toml_ |
| 62 | + - Verify all dependencies pass using `cargo vet` |
| 63 | + |
| 64 | +5. **Decide audit location**: |
| 65 | + - **Shared audits**: New audits should ideally be shared across ODP repositories to reduce the overhead of multiple audits for the same dependencies. To facilitate this, it's recommended to cut and paste the new audits and submit as a separate PR to the _audits.toml_ in [rust-crate-audits](https://github.com/OpenDevicePartnership/rust-crate-audits) |
| 66 | + - If due to business reasons, the audits are not to be shared across repositories, copy the updated _audits.toml_ to a new branch off main in the same repository and submit the PR to update the audits |
| 67 | + |
| 68 | +6. **Communicate successful audit**: |
| 69 | + - Communicate to the PR developer via a PR comment so they can update the PR and get `cargo vet` to pass |
| 70 | + |
| 71 | +--- |
| 72 | + |
| 73 | +## Audit criteria |
| 74 | +`cargo vet` comes pre-equipped with two built-in criteria but supports adding new criteria to suit our needs. |
| 75 | +As defined [here](https://mozilla.github.io/cargo-vet/built-in-criteria.html), the default criteria are: |
| 76 | + |
| 77 | +- **safe-to-run** |
| 78 | + This crate can be compiled, run, and tested on a local workstation or in |
| 79 | + controlled automation without surprising consequences, such as: |
| 80 | + * Reading or writing data from sensitive or unrelated parts of the filesystem. |
| 81 | + * Installing software or reconfiguring the device. |
| 82 | + * Connecting to untrusted network endpoints. |
| 83 | + * Misuse of system resources (e.g. cryptocurrency mining). |
| 84 | + |
| 85 | +- **safe-to-deploy** |
| 86 | + This crate will not introduce a serious security vulnerability to production |
| 87 | + software exposed to untrusted input. |
| 88 | + |
| 89 | + Auditors are not required to perform a full logic review of the entire crate. |
| 90 | + Rather, they must review enough to fully reason about the behavior of all unsafe |
| 91 | + blocks and usage of powerful imports. For any reasonable usage of the crate in |
| 92 | + real-world software, an attacker must not be able to manipulate the runtime |
| 93 | + behavior of these sections in an exploitable or surprising way. |
| 94 | + |
| 95 | + Ideally, all unsafe code is fully sound, and ambient capabilities (e.g. |
| 96 | + filesystem access) are hardened against manipulation and consistent with the |
| 97 | + advertised behavior of the crate. However, some discretion is permitted. In such |
| 98 | + cases, the nature of the discretion should be recorded in the `notes` field of |
| 99 | + the audit record. |
| 100 | + |
| 101 | + For crates which generate deployed code (e.g. build dependencies or procedural |
| 102 | + macros), reasonable usage of the crate should output code which meets the above |
| 103 | + criteria. |
| 104 | + |
| 105 | + **Note: `safe-to-deploy` implies `safe-to-run`** |
| 106 | + |
| 107 | +--- |
| 108 | + |
| 109 | +## Conducting an audit |
| 110 | + |
| 111 | +When performing an audit for a new or updated dependency, auditors may consider the following criteria to ensure the safety, reliability, and suitability of the crate for use in our projects: |
| 112 | + |
| 113 | +- **Security**: |
| 114 | + - Review the crate for known vulnerabilities or security advisories. |
| 115 | + - Check for unsafe code usage and ensure it is justified and well-documented. |
| 116 | + - Evaluate the crate’s history of security issues and responsiveness to reported problems. |
| 117 | + |
| 118 | +- **Maintenance and Activity**: |
| 119 | + - Assess the frequency of updates and the responsiveness of maintainers to issues and pull requests. |
| 120 | + - Prefer crates that are actively maintained and have a healthy contributor base. |
| 121 | + |
| 122 | +- **License Compliance**: |
| 123 | + - Verify that the crate’s license is compatible with our project’s licensing requirements. |
| 124 | + |
| 125 | +- **Community Trust and Adoption**: |
| 126 | + - Consider the crate’s adoption in the wider Rust ecosystem. |
| 127 | + - Prefer crates that are widely used and trusted by the community. |
| 128 | + |
| 129 | +- **Functionality and Suitability**: |
| 130 | + - Confirm that the crate provides the required functionality without unnecessary features or bloat. |
| 131 | + - Evaluate whether the crate’s API is stable and unlikely to introduce breaking changes unexpectedly. |
| 132 | + |
| 133 | +- **Audit Trail**: |
| 134 | + - Record the audit decision, including any concerns, mitigations, or recommendations for future updates. |
| 135 | + - If exemptions are granted, document the justification and any follow-up actions required. |
| 136 | + |
| 137 | +--- |
| 138 | + |
| 139 | +## Tips for using `cargo vet`: |
| 140 | + |
| 141 | +- **Update _imports.lock_**: |
| 142 | + - Import trusted third party audits to reduce the number of new audits to be performed. Running `cargo vet` without `--locked` fetches new imports and updates _imports.lock_ with any audits that are helpful for our project. |
| 143 | + |
| 144 | +- **Add exemptions**: |
| 145 | + - If an audit cannot be performed for some dependency due to time sensitivity or business justified reasons, use `cargo vet add-exemption <PACKAGE> <VERSION>` to add the dependency to exemptions in _config.toml_ |
| 146 | + - To add all remaining audits to exemptions at once, use `cargo vet regenerate exemptions` |
| 147 | + |
| 148 | +- **Prune unnecessary entries**: |
| 149 | + - Remove unnecessary exemptions and imports using `cargo vet prune` |
0 commit comments