Replies: 2 comments 2 replies
-
|
I realize this is a complication for anti-spam actions, and ends up "wasting" potentially nice versions on spam. Possible solutions:
|
Beta Was this translation helpful? Give feedback.
-
This would make it impossible to reclaim crate names from squatters, so I don't belive that is a viable option. Same goes for the last option, just because I reclaimed a squatted name I will now have to start on a version I'm not ready to use. Sure, starting on 0.2 is not a big deal, but if the previous semver version is already 1.0 I would start on 2.0. I might not be ready to indicate that my crate is that stable yet. Major versions different than 0 carry different connotations to humans, even if from a purely rust semver perspective it makes no difference. I believe even your lib.rs assumes this. Or at least that is what I assumed the different colours of the version number of a crate indicates. |
Beta Was this translation helpful? Give feedback.
-
If the 1.0 version were yanked, couldn't you publish 0.1000.0 and have it be the latest (accessible) version? Then move on to 1.4 (or whatever minimum minor version you need) when ready to go 1.x? |
Beta Was this translation helpful? Give feedback.
-
|
maybe there needs to be a per-name epoch (kinda like how debian does it), so when a name is totally removed, the epoch is incremented so any new crates with the same name don't conflict even if they have the same version string. that way a |
Beta Was this translation helpful? Give feedback.
-
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,immutablewhich 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
Environment
N/A
Anything else?
The checksum changes happened quite a few times:
Beta Was this translation helpful? Give feedback.
All reactions