search

rust-lang / rfcs

RFCs for changes to Rust
https://rust-lang.github.io/rfcs/
Apache License 2.0
5.78k stars 1.55k forks source link

Add "crates.io: Crate Deletions" RFC #3660

Open Turbo87 opened 1 week ago

Turbo87 commented 1 week ago

Rendered

kornelski commented 1 week ago

Maybe require all crate versions to be yanked for at least $long_time.

Turbo87 commented 1 week ago

How does this help me rename my crate that has users?

it doesn't. this will only be helpful for renames very early in a project's lifespan. for example: you discovered after two days that you wanted to use hyphens instead of underscores or vice versa. this won't help e.g. tokio rename itself to kyoto

Maybe require all crate versions to be yanked for at least $long_time.

This would likely have consequences for the 72 hour rule. npm allows deletion without prior deprecation (which I treat roughly similar to our yanking). if you made a publishing mistake, such a rule would probably prevent people from being able to quickly fix their mistake.

clarfonthey commented 1 week ago

I'm mostly in favour of this change, but with one caveat: I think that there should be an explicit mention that, while deleting a crate or version will immediately remove it from public downloads, crates.io should reserve the right to retain the deleted version for some amount of time (maybe a few days after deletion) just as a safeguard from abuse.

72 hours is a pretty long time, and just thinking of how this feature could be abused, you could upload malicious content for that interval, then "get rid of the evidence" pretty quickly. Effectively, I think that it should be possible for someone to notice that abuse occurred, report it, and then have someone review the deleted content before it's immediately sent to the shadow realm. Doesn't have to be long, but it feels like a safeguard that should exist if this feature is added, and it should be one that's clarified does exist.

Additionally, I think that the current requirements beyond the 72-hour window are a bit strict, and would exclude some crates that I personally think might be worth including under this policy. For example, take this incredibly old crate: https://crates.io/crates/bow

I am the owner of this crate, but it relied on the long-fixed incoherent_fundamental_impls soundness hole, and is now broken permanently on all versions of Rust since… a while. Six years ago, I published an explicitly empty version to the crate including a message about how it's broken, and back before I really understood everything, I didn't yank the old, broken versions. In fact, I should probably go and do that now.

However, through a series of also-broken dependencies by me that I also haven't checked in years, is part of the swc-hosts crate, which is downloaded a handful of times a day. In fact, it was downloaded 54 times on Jun 11, so, my guess is that someone has it running in their CI somewhere, and this itself is massively inflating the number of downloads.

Now, as I said, I'm going to probably take a bit within the next few days to go and make sure all of these crates have a blank latest version that does nothing, and their past versions are all yanked. But doing this now, after 6 years, means I'm basically never going to cover that 100-download-per-month requirement unless I have another several years where I have no downloads at all. (Which will happen, but, yeah.)

My proposal for this is to modify the rules slightly: as an alternative to the 100 downloads requirement, allow crates whose latest version satisfies the 100 downloads requirement but whose versions which do not satisfy that requirement are over a year old and have never been downloaded more than 100 times a day. This allows those pesky CI outliers to be weeded out while still effectively meaning that nobody uses the crate.

maia-s commented 1 day ago

100 downloads is too low. I'm an unknown crate author and I've released a few crates with no dependents and no advertising of the crates at all. They've all easily reached 100 downloads in the first one or two days. Bots keep downloading old versions of crates too, so each new version essentially acts as a multiplier for bot downloads. Also, releasing multiple new versions of a crate in quick succession (e.g. to fix semver breaks) seems to exponentially increase the number of bot downloads. One of my crates got a thousand bot downloads in a day and currently has 3700 downloads, more than twice the downloads of the crate it depends on. To my knowledge nobody uses it yet.