Certified/Mandatory CI uploads #1462
Description
After the recent ESLint incident, there has been some discussion on how to prevent accidents like this.
Package registry tends to be very opaque since you will almost never inspect what code you download (but just build them directly). Thus, ensuring the integrity of the uploaded code is important, and one way to improve the transparency is to enforce upload from CI.
The concept is similar to reproducible builds, where you can have consistent artifacts with a given source. Although enforcing CI uploads doesn't require reproducibility, we can:
- Make the source getting uploaded associated to a tree on GitHub (which can be reviewed easily)
- Optionally enforcing signing tags
- Make the procedure that may generated any source clear
To present this to a user, I propose the following approach:
- Crate owners may set settings to enforce uploads from CI, with the following options:
- Allow upload from CI? (User may choose exactly one CI provider and must associate a GitHub repository)
- Require tags to be signed?
- Enforce uploads from CI?
Edit: User may choose another hosted provider (if we support), like Bitbucket or GitLab.com. However, whether to support self-hosted Git solutions needs to be discussed, as it's easier to compromise than shared hosting services.
- Upon upload, crates.io will perform verification that it's really the CI with the following method:
- Cargo dumps the hash of the tarball into CI log. (The tarball includes
Cargo.toml, thus the hash takes crate version into account) - Cargo initiate an upload request to crates.io. No token is involved.
- crates.io fetches the job metadata from the CI's API. The repo and tag must match the version getting uploaded.
- crates.io fetches the log of the job and verifies that it contains the hash of the tarball.