Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
kornelski opened this issue May 10, 2025 · 1 comment
Closed

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

kornelski opened this issue May 10, 2025 · 1 comment

Comments

@kornelski
Copy link
Contributor

kornelski commented May 10, 2025 •
edited
Loading

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:
@kornelski
Copy link
Contributor Author

kornelski commented May 10, 2025 •
edited
Loading

I realize this is a complication for anti-spam actions, and ends up "wasting" potentially nice versions on spam. Possible solutions:

  • Keep deleting crates if needed, but also keep an extra table server-side with (name, version) => checksum mapping that never gets removed. Refuse to publish the same (name, version) if the checksum differs. If a new owner hits this case, tell them to bump the version. I think that's the best, least disruptive solution.
  • Yank all existing versions, remove all owners, but don't delete the crates. Display these crates as non-existent/deleted on the web front-end, but keep versions and their checksums intact in the index.
  • I've suggested previously that if crates.io were to give abandoned or squatted crates to new owners, it could forbid the new owners from publishing old semver-compatible versions to prevent new owners from automatically affecting any potential old users (have a concept of a minimum version that can be published, and set it to semver-major+1 of the previous owner's versions). This logic could be reused for deleted & reclaimed crates, although it's not ideal in case of spam.

@rust-lang rust-lang deleted a comment May 12, 2025
@rust-lang rust-lang locked and limited conversation to collaborators May 12, 2025
@Turbo87 Turbo87 converted this issue into discussion #11161 May 12, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@kornelski