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

Conflicting info about yanking crates #1914

Open
sunshowers opened this issue Mar 5, 2024 · 5 comments
Open

Conflicting info about yanking crates #1914

sunshowers opened this issue Mar 5, 2024 · 5 comments

Comments

@sunshowers
Copy link
Contributor

While trying to resolve RUSTSEC-2024-0020, we found some conflicting information (ardaku/whoami#97 (comment)):

Which one of these recommendations controls?

@tarcieri
Copy link
Member

tarcieri commented Mar 5, 2024

It seems like the Cargo docs discourage yanking for security vulnerabilities as disruptive, but IMO there is no reason not to yank a crate for a security vulnerability if there is a SemVer-compatible upgrade. Yanking becomes disruptive when there is no SemVer-compatible upgrade.

@sunshowers
Copy link
Contributor Author

Thanks Tony! Do you think you could work with Cargo upstream to clarify the situation?

@tarcieri
Copy link
Member

tarcieri commented Mar 5, 2024

Yeah, it'd be good to open an issue about syncing this advice with RustSec

@EliahKagan
Copy link
Contributor

It seems to me that the advice here should also be narrowed. Something like:

-4. [Yank] the affected versions of the crate.
+4. [Yank] the affected versions of the crate, if a SemVer-compatible upgrade is available.

But I worry that may not be quite right, because there are probably uncommon circumstances where yanking vulnerable versions should be done even in the absence of a SemVer-compatible upgrade. For example, in a vulnerability where a malicious dependency was accidentally used, usually it can be eliminated without a breaking change, but yanking is probably justified even if it cannot.

@sunshowers
Copy link
Contributor Author

Maybe we could provide general advice and a list of special cases to consider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants