Implement Verifiable Mirroring Prototype

[tomassedovic]

Metadata
Point of contact	@walterhpearce
Team(s)	cargo, crates-io, infra, rustup
Goal document	2026/mirroring

Summary

We aim to ship a Minimum Viable Product that provides cryptographically verified mirrors for Rustup and Cargo, specifically targeting high-traffic environments like GitHub Actions (GHA) runners on Azure. By utilizing The Update Framework (TUF), we will establish a secure, multi-key distribution model that reduces infrastructure costs while providing for utilizing TUF as a validating mechanism on the backend transfers for mirroring, while integrating the needed unstable features into Rustup and Cargo for implementation. Our goal is to implement a first trial pass of [RFC #3724], with modifications, allowing for mirrors of Rust releases and crates to be configurable or automatically utilized by the Rustup toolchain.

We plan to trial TUF validation on these mirrors in a phased approach, starting on the server-side prior to any client-side integrations. Specifically, we plan to work in the following phases:

1. Implement unstable mirror URL specifications for client software (rustup and cargo)
2. Deploy infrastructure at alternative locations for mirroring (Azure, GCP)
3. During mirror propagation, on the server side, utilize TUF to validate mirror updates
4. Upon coming to consensus on this backend validation, we will migrate the implementations to unstable client-side features

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@walterhpearce
Team(s)	cargo, crates-io, infra, rustup
Goal document	2026/mirroring

Summary

We aim to ship a Minimum Viable Product that provides cryptographically verified mirrors for Rustup and Cargo, specifically targeting high-traffic environments like GitHub Actions (GHA) runners on Azure. By utilizing The Update Framework (TUF), we will establish a secure, multi-key distribution model that reduces infrastructure costs while providing for utilizing TUF as a validating mechanism on the backend transfers for mirroring, while integrating the needed unstable features into Rustup and Cargo for implementation. Our goal is to implement a first trial pass of RFC#3724, with modifications, allowing for mirrors of Rust releases and crates to be configurable or automatically utilized by the Rustup toolchain.

We plan to trial TUF validation on these mirrors in a phased approach, starting on the server-side prior to any client-side integrations. Specifically, we plan to work in the following phases:

1. Implement unstable mirror URL specifications for client software (rustup and cargo)
2. Deploy infrastructure at alternative locations for mirroring (Azure, GCP)
3. During mirror propagation, on the server side, utilize TUF to validate mirror updates
4. Upon coming to consensus on this backend validation, we will migrate the implementations to unstable client-side features

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[JoelMarcey]

Current Work

Arlo is updating the rust-tuf implementation to support more signing algorithms (ECDSA), improved key-ID handling (TAP12), and a DSSE-based POUF to replace the current canonical JSON-based POUF. Because a new POUF is not compatible with existing tuf-on-ci, Arlo is also building specific replacement tooling in Rust. Walter has shifted his primary focus on TUF for the foreseeable future and is concentrating on rustup and Rust release integration.

Proposed Architecture

Set up a tuf-on-ci style repository on GitHub as our backing store for TUF. This TUF repository will secure:

• Names/hashes of channel manifest files for the toolchain
• Names/hashes of the rustup releases for rustup
• Names/hashes of one or more trusted signing keys for crates.io

The git repository will not contain the actual files, as those will be hosted in HTTP object storage (S3). The files should have permanent names (using hash-based content addressing) to avoid any tearing issues between the TUF repository state and the CDN.

The GitHub repository will be used to manage the root quorum and rotate online signing keys using an approach similar to tuf-on-ci. A local CLI tool will be developed that interacts with the repository for signing events. The CLI tool will use a YubiKey for performing the signing operations, and post to GitHub Pull Requests during the signing process. The contents of the git repository will be published to the object storage and CDN for access by clients when it changes. Clients do not access the git repository directly.

We intend to structure the crates.io index as a merkle tree, such that a single hash is sufficient to describe the contents of the index at a given point in time. Since the contents of crates.io changes so frequently, rather than securing the artifacts directly in TUF, the TUF repository will be used to distribute trusted public keys that are used to sign the root of the crates.io merkle tree. The signature will have a short expiration (as short as the shortest TUF role (timestamp)) so that it requires constant online re-signing, which will be handled by crates.io.

Key Questions

There are still some questions:

• whether the DSSE-based POUF is the right choice
• the exact TUF delegation and repository layout
• how Rust's release staging process should work with TUF
• whether rustup needs its own manifest format or TUF metadata alone is sufficient
• whether GCP publishing should happen through Rust tooling or GitHub Actions
• whether stable Rust releases should eventually support YubiKey signing

Division of Work

Arlo is leading Rust TUF changes, the DSSE POUF, the tuf-on-ci replacement, server-side publishing, and crates.io signing architecture. Walter is working on rustup/client integration, Rust release and channel-manifest work, staging investigation, and testing Arlo's TUF work.

Some Next Steps

Arlo will continue building the server-side TUF tooling using DSSE POUF. Walter can continue developing locally now and will test Arlo's branch for interoperability. Arlo will continue to develop a proposed crates.io trusted-signing-key architecture. Arlo will continue rust-tuf improvements in the tbdsigning branch. Arlo will build a tuf-on-ci port using rust-tuf instead of Python. Walter and Arlo will raise release and staging questions with Mark and others at an upcoming project-wide signing sync. Walter will hold off on the GCP CI integration until Arlo determines whether the Rust tooling itself needs direct GCP access. Walter discusses rustup manifest/packaging changes with Dirkjan.

Overall, we have a clearer architecture and division of responsibilities, but several important choices such as the DSSE POUF and repository structure remain.