Information is misleading for a crate that has all of its versions yanked

[MaciekTalaska]

I think currently the text that is being shown when navigating to a crate that has all of its versions yanked is misleading. It currently states:

This crate has been yanked, but it is still available for download for other crates that may be depending on it.

You may wish to view all versions to find one that has not been yanked.

This is not true, if all versions are yanked. I think that for clarity it should be changed to inform the user that it is not possible to use the crate at all.

Please find an example: https://crates.io/crates/wcwidth

[smarnach]

We are happy to update the text to make it clearer, but I'd first like to understand what exactly caused the misunderstanding.

"Available for download" in this context means that the crate can still be downloaded by Cargo when it is needed by dependent crates. You can also download it manually via the API:

curl -L https://crates.io/api/v1/crates/wcwidth/1.12.1/download --output wcwidth-1.12.1.crate

So I believe this description is accurate.

How did you come to the conclusion that you can't download the crate anymore? Can you suggest a wording that would be less confusing for you?

[carols10cents]

A more accurate but also more jargon-y description is "If you have the yanked crate referenced in a Cargo.lock file, Cargo will download the crate for you. If Cargo is creating or updating a Cargo.lock file, it will not create a new dependency on the yanked crate/version."

That's what we tried to say with "for other crates that may be depending on it." but I can see what you mean about that being unclear.

I think that for clarity it should be changed to inform the user that it is not possible to use the crate at all.

This isn't quite accurate either; it is not possible to start depending on the yanked crate, but existing projects with existing lock files will continue to work (and the crate file is still available, as smarnach mentioned.

Do you have any ideas for a better way to explain what actually happens?

[MaciekTalaska]

Thank you for your explanation & apologies for such a delay in replying.

@smarnach

"Available for download" in this context means that the crate can still be downloaded by Cargo when it is needed by dependent crates. You can also download it manually via the API:

curl -L https://crates.io/api/v1/crates/wcwidth/1.12.1/download --output wcwidth-1.12.1.crate

I must confess I haven't tried that before.

I have just used curl as in your example and I got wcwidth downloaded - I am still not sure what do I do with it right now :)

So I believe this description is accurate.

How did you come to the conclusion that you can't download the crate anymore? Can you suggest a wording that would be less confusing for you?

Well, what I tried to do was:

1. Create a new project
2. Added yanked crate as dependency (wcwidth)

and just because all versions of wcwidth are yanked it is not possible to compile such a project - that lead me to (wrong) conclusion that it is impossible to download a crate that has been yanked. more, I thought that this is by design how the mechanism should work.

I think I understand the importance of having "yank" mechanism in place - I am not questioning that. The thing is I believe that the information should be more detailed (unless I am the only one having a little bit of problem understanding this behavior).

@carols10cents

A more accurate but also more jargon-y description is "If you have the yanked crate referenced in a Cargo.lock file, Cargo will download the crate for you. If Cargo is creating or updating a Cargo.lock file, it will not create a new dependency on the yanked crate/version."

That's what we tried to say with "for other crates that may be depending on it." but I can see what you mean about that being unclear.

so that is a huge difference for me when it comes to understanding "yanking a crate". I would very much prefer the more informative, more detailed version. I know we all want to be accurate and form short messages, but sometimes more details are actually better.

This isn't quite accurate either; it is not possible to start depending on the yanked crate, but existing projects with existing lock files will continue to work (and the crate file is still available, as smarnach mentioned.

I am confused again - so I may download the crate, but still can't start a project depending on it? Why then make it possible to download the crate in the first place then? Is there any reason for it? Sources should be available for viewing purposes without the need of downloading a crate.

Yet I do understand that having a crate yanked, and allowing user to download it and start a new project with dependency on yanked crate seems like something that was not intended to happen.
On the other hand - maybe user should be allowed to decide on their own (using some kind of --allow-yanked or sth similar in cargo)?

@carols10cents & @smarnach

Taking your input I have spent some time trying to figure out how to add some extra info for those (like me) having a bit of a problem understanding what does that mean that "crate is yanked".

I think something like below should be more informative:

This crate has been yanked, but it is still available for download for other crates that may be depending on it.

<I think it is important to tell the user what does that mean that crate is yanked, explain that briefly>
Yanking a create usually happens when some code vulnerabilities in the code of the crate are found and thus such a crate should not be used for security concerns (until all security related bugs are fixed).

In case you want to download the crate:

curl -L https://crates.io/api/v1/crates/wcwidth/1.12.1/download --output wcwidth-1.12.1.crate

<it would be nice to either link to, or describe how to "use" downloaded crate or why user may want to download it, explain why it is not possible to start a new project using yanked crate>

You may wish to view all versions to find one that has not been yanked.

<and the nicest thing here would be presenting alternatives to yanked crate - possibly based on keywords & categories>

What do you think? Does that make any sense?

[smarnach]

The yanking mechanism tries to achieve two conflicting goals:

• Allow crate authors to revoke crate versions that shouldn't be used.
• Don't break working software.

If a yanked crate gets completely deleted, all crates depending on it will immediately break, so we don't want to do that. If we still allow all uses of a yanked crate, yanking wouldn't work well as a revocation mechanism. So the compromise is that existing dependencies on a yanked version will continue to work as before, while Cargo will never introduce a new dependency on a yanked version.

The message we currently show is probably not ideal. One problem is that we use the same message for two different cases:

• When trying to view a crate with all versions yanked, e.g. https://crates.io/crates/wcwidth.
• When trying to view a yanked version of a crate, e.g. https://crates.io/crates/futures/0.2.0.

If we want to give users a more useful explanation, I think we should show different messages for these two cases.

[Turbo87]

I believe we resolved the original issue with #6415, so I'll close the issue now :)