Certified/Mandatory CI uploads

[ishitatsuyuki]

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:

1. Make the source getting uploaded associated to a tree on GitHub (which can be reviewed easily)
2. Optionally enforcing signing tags
3. Make the procedure that may generated any source clear

---

To present this to a user, I propose the following approach:

1. 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.

2. 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.

[carols10cents]

must associate a GitHub repository

We don't currently mandate the use of GitHub for projects, only for account creation (and account creation might not be GitHub-only forever). There are projects that host their code on gitlab, bitbucket, or personal websites.

[jokeyrhyme]

Before cryptocurrency mining ruined everything, Docker had a neat model, in that you would register your public source repository within the public Docker Hub, and the Hub would register its own webhooks for notification when you committed to main, and it would use the Hub's own build/compute resources to read your source code, build your Docker file, and publish your image

Because the full chain of custody from commit to registry was controlled by the Docket Hub, they could mark these images as such

Now that public-good compute has been ruined forever, I suppose we need a new way to maintain this trust/chain-of-custody without relying on free compute resources