Skip to content

Published crate versions are not immutable, and have changed #11150

New issue
New issue
Closed
Closed
Published crate versions are not immutable, and have changed#11150
@kornelski

Description

@kornelski
kornelski
opened on May 10, 2025

Current Behavior

Usually crates.io refuses to change existing releases. However, if a crate is deleted (by admins), then it's possible to reclaim the name, and publish the same version of the same crate with a new content.

This means that the index (apart from yanking) isn't truly immutable/append-only. It's possible that for a given (crate_name, version) there will be a different content at different times.

This edge case creates problems:

  • It complicates registry caching/mirroring. I can't assume that each crate version is published only once ever. Tarballs are downloaded by name & version, but must match the checksum in the index (BTW, static.crates.io sends cache-control: public,max-age=31536000,immutable which isn't correct!). Properly supporting that edge case requires ability to purge caches.

  • Similarly, it complicates data analysis. I can't assume that data derived from a release won't change, so I need to have ability to update previously processed data. I've assumed that the registry data is append-only and crate tarballs can't change, and ended up with inconsistent data on https://lib.rs for republished crates.

  • It prevents implementation of an extra TOFU-like security for clients. I wanted to add an extra layer of security to my crates.io mirror (and propose a similar policy in Cargo) that enforced that checksums of published crates must never change. This would ensure that existing releases couldn't be modified even if crates.io itself was hacked, and any attempts to do so could be detected and raise an alarm (I know crates.io is working on a proper security model, but this would have been an improvement without protocol changes). Unfortunately, the possibility of delete + republish legitimately changing the content of old crates is an exception that makes checksums effectively mutable.

Expected Behavior

Would it be possible for crates.io to make checksums always immutable?

Steps To Reproduce

  1. Claim a previously deleted crate.
  2. Publish a version that used to exist.

Environment

N/A

Anything else?

The checksum changes happened quite a few times:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions