Replies: 4 comments 22 replies
-
|
I realize this is a complication for anti-spam actions, and ends up "wasting" potentially nice versions on spam. Possible solutions (updated):
|
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.
-
|
Yanked versions don't participate in the selection of the latest version, so if a squatter released 1.0.0 already, you couldn't re-release 1.0.0, but you could release 1.0.1, and any other not yet claimed patch version like 1.0.999999. Yanked later versions also don't stop you from having some not-yet-released 0.1.12345 as your first release. That's not pretty, but still perfectly functional. As they say in SemVer — numbers are cheap and plentiful. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to note that crates.io does have this currently, when a user or an admin deletes a crate there's an crates.io/src/controllers/krate/delete.rs Lines 116 to 125 in e636437 And the value is currently 24 hours: crates.io/src/controllers/krate/delete.rs Line 23 in e636437 |
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.
-
|
What about the case where a crate becomes malicious? For example, what is the procedure if a Jia Tan "visits" a Rust crate? Is the whole crate nuked? Just the known-tainted versions? The versions since (known) contributions started? Is it different if the cause is intentional or incidental (e.g., some supply chain fault in a |
Beta Was this translation helpful? Give feedback.
-
|
For the xz scenario, wouldn't just the bad versions get yanked + deleted? I don't think there is a need for a new epoch, those versions could just be rejected as if they had been yanked (but with the additional step that you also can't download them or force update to them). |
Beta Was this translation helpful? Give feedback.
-
Not sure; I think There's also the "nice crate you've got there, how about a cashout?" that has happened with browser addons and (IIRC) some NPM packages where the maliciousness is more persistent than one-off. |
Beta Was this translation helpful? Give feedback.
-
|
From UI perspective, I would treat change of epoch like an unrecoverable dead-end error, or a very scary alert about a security vulnerability, sort of like SSH treats change of the server's key. The epoch can change only when the crate is completely deleted and can be reclaimed by anybody else, so after epoch bump it's no longer the same crate, not the same version, and most likely not the same owner. There's no way to get the original crate back, so it's an unrecoverable error. Any attempt to work around that may end up installing malware. |
Beta Was this translation helpful? Give feedback.
-
|
yeah, i guess i got all caught up in the epoch is now effectively part of the version and forgot that an epoch change means you now have a completely unrelated crate. |
Beta Was this translation helpful? Give feedback.
-
|
It seems like there's some sort of data modeling mismatch here... One way to think of crate version/checksum relations is:
But another way to think of it is:
In the latter mental model, checksums are immutable: if the The point being that the checksum hasn't changed-- it's a new, appended record (because the crate is completely different). GIven this mental model, I'm not sure that crates.io needs to change anything about policies or disallowing version number reuse? What am I missing? Another thought I have is what if systems like libs.rs could consume notifications of deletes and remove entries from its systems when deletes are detected? Would that solve the issue? |
Beta Was this translation helpful? Give feedback.
-
|
That's a very good way of framing it. I think we currently have a mix of different assumptions in different places about what the primary key is. Reclaiming/republishing of versions makes it
Notifications are not necessary for https://lib.rs. I can make it watch for changes in the checksum instead. The pain is in having to implement cache invalidation, and track down all the places where I'm currently working on a different project that is a private mirror of the crates.io registry for a high-security project that needs to stay safe in the event crates.io infrastructure got hacked. For this purpose a deletion notification from crates.io could not be trusted. Because |
Beta Was this translation helpful? Give feedback.
-
|
Also note that user deletions are not allowed if there are other crates on crates.io that depend on that crate. From the page you see when attempting to delete a crate:
As admins, we only delete crates that have dependencies if there's a very good reason (such as some sort of legal action). This of course doesn't protect projects not on crates.io that depend on a crate, but the hope is these restrictions make it so that widely used crates won't get into the problematic situations being discussed here. |
Beta Was this translation helpful? Give feedback.
-
|
What happens in the xz scenario? Where certain versions contain malware? Would those versions get fully deleted so that they can never be downloaded? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we have deleted versions with malware in those cases (even if there are dependencies). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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