Skip to content
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.

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

Start requiring a reason for all yanks #2608

Open
alexcrichton opened this issue Apr 22, 2016 · 9 comments
Open

Start requiring a reason for all yanks #2608

alexcrichton opened this issue Apr 22, 2016 · 9 comments
Assignees
Labels
A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-yank S-triage Status: This issue is waiting on initial triage.

Comments

@alexcrichton
Copy link
Member

alexcrichton commented Apr 22, 2016

@wycats, @nikomatsakis and I have discussed recently the ability to yank a crate with a reason, and then whenever that yanked crate is compiled locally it will present the reason as a warning.

The intended use cases for this would be:

  • When a crate is fixed because it will be broken in the next version of the compiler (e.g. a soundness fix or bug fix) then the previous versions can be yanked and nudge users forward.
  • If a crate is fixed for a security reason, the old versions can be yanked and the new version can be suggested
  • If a crate is renamed (or perhaps deprecated) to another then the yank message can indicate what to do in that situation.

Technically, I believe this should be implemented through:

  1. Update crates.io to accept an optional message for yanks. Store it in the database.
  2. Update cargo yank to require a message indicating why the crate is being yanked.
  3. Change the logic for when a yanked crate is compiled to something like:
    • Use whatever state the registry is currently in, do not update it.
    • Only issue a warning if the crate is compiled, not if it is "fresh" (e.g. has already been compiled).
    • When compilation starts, fire off an asynchronous HTTP request to crates.io to fetch the yank message.
    • Print out the warning whenever the HTTP request finishes or block the build finishing on these HTTP requests to return.
    • Ignore any errors that happen fetching the yank message, they should not fail the build.

I think this should suffice as an "opportunistic nudge" for these situations where possible, although it's certainly no form of ironclad guarantee.

Thoughts @wycats, @nikomatsakis?

@Mark-Simulacrum
Copy link
Member

If we can standardize the yank text to a small list we could store it in the index and avoid the HTTP overhead for the common case.

@kornelski
Copy link
Contributor

For the yank of futures 0.2 something like "please use futures-preview instead" would be a useful yank message. Small list of predefined messages wouldn't cover it, unless you allowed parametrized messages, but that might be too much complexity for little gain.
If yank messages have a length limit (e.g. 80 chars?) putting them in the index shouldn't be too bad.

@tarcieri
Copy link

tarcieri commented Dec 19, 2018

Note: there's some discussion of this issue in the context of this thread: https://internals.rust-lang.org/t/pre-rfc-reviving-security-advisories-in-crates-io-rfc-pr-1752/9017/11?u=bascule

Namely that if the "yank message" that gets persisted to the crates.io index can be something like a structured TOML file, a mechanism like this could potentially be used for storing RustSec security advisories in the crates.io index.

However, for that purpose, it would be helpful if the "yank message" could span yanking multiple releases of the same crate.

@DevQps
Copy link

DevQps commented Mar 16, 2019

I think this would be a great idea. Especially to have some kind of categories signalling why it was yanked together with a more explanatory description. I do however wonder if some authors that just want to quickly yank something will not choose "bug" instead of "security" for example. Maybe an interactive version with a question like: "Does this version expose vulnerabilities?" or something like that.

@tesuji
Copy link
Contributor

tesuji commented Oct 10, 2019

Hi. I would like to see this feature. I yanked two versions of home crate (0.4.1 and 0.4.0)
because they failed to build on Windows.
It would be better if I could inform this to all dependent crates.

@kentfredric
Copy link

It might be useful also to have a mechanism to update the yank reasons.

For instance, if a crate is yanked due to a CVE, then the first time its yanked, it would have that CVE.

However, when CVEs are published, they tend to enumerate 'ranges of affected versions', so its entirely feasible that one wishes to retroactively document in the yank reason any applicable new CVE's that may apply.

But you can see the direction this is heading. The ultimate desire is to encourage consumers to head in the right direction, but to also provide adequate information to give consumers grounds to make choices. Naturally, if a user sees a CVE, and the CVE vector is remote access, and their product doesn't have any remote access capacity (eg: embedded device without a network peripheral of any description), then they'd be fine with ignoring the CVE if upgrading to avoid the CVE would cause some kind of detriment to what they're doing.

Just as-is, this is all terribly obscure and you need to reach for 3rd party tools to even have a hope of making the right decision, as nothing exists to encourage crate authors to inform their users in a consumable way ( "read the README of every crate in your graph, good luck mate!" )

@desandy
Copy link

desandy commented Jun 10, 2021

I would very much like to see this feature. I believe there are many valid use cases. Otherwise, the manner available is to contact the crate maintainers and request a reason.

If you are using a yanked crate and need to make a determination as to its fitness for usage for your project, you are left with no information. Especially if the yanked crate is the latest version. Then should I downgrade, is there a truly compelling reason?

Leaving the ability to yank to the discretion of the developer is wonderful, but, I also believe crates are "yanked" for the wrong reasons. So, simply having a description of why they chose to yank it would be very helpful.

@epage
Copy link
Contributor

epage commented Feb 7, 2024

Unsure why the proposed solution has the yanked message accessible through an API call to the registry, rather than as part of the Index. My main guess is people will rarely need it and it can keep the size of Index entries smaller.

If we do keep a side-band database for mutable state, some other potential uses

A less developed idea is to provide a way to distribute information relevant to #7193.

I talk a little about this database idea in rust-lang/rust#106060 (comment)

@Rustin170506
Copy link
Member

My main guess is people will rarely need it and it can keep the size of Index entries smaller.

Yes. I think that would be the main reason. But if we set a length limit, it would help us to keep it relatively small.

I will assign this issue to myself. I will bring it to the crates.io team meeting next week and get some initial feedback from the team. (At least check if they have any objections or thoughts before I submit the pre-RFC)

@rustbot claim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-interacts-with-crates.io Area: interaction with registries C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-yank S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests