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

Guidance around yanking crates? #74

tarcieri opened this Issue Dec 6, 2018 · 3 comments


None yet
3 participants
Copy link

tarcieri commented Dec 6, 2018

I think it makes sense to encourage people to yank all releases of any crate which match any vulnerable versions listed in advisories.

This could range from a heavy-handed lint on published crate versions which requires all impacted versions for a crate be yanked before the advisory can be merged, to a lighter touch "you should probably yank those crates" advice in both and as a pull request comment.

What do people think about this?

@tarcieri tarcieri added the question label Dec 6, 2018


This comment has been minimized.

Copy link

bluejekyll commented Dec 11, 2018

I think there are some scenarios to consider in this that might make it problematic. One example I can think of is that people may be relying on older crates if they are building with older versions of the Rust compiler, yet there hasn't been a patch applied to the older versions of the code (maintainers won't have the time/capacity to go back and patch "supported" versions).

I don't know what the right answer is here, my knee-jerk response is to agree with this proposal, but I think it could have untoward effects in the wider ecosystem.


This comment has been minimized.

Copy link

8573 commented Dec 21, 2018

My one concern with a requirement that vulnerable versions be yanked is that it would seem to mean that filling vulnerability advisories would begin to require the cooperation of crate owners.


This comment has been minimized.

Copy link

tarcieri commented Dec 21, 2018

@8573 that is a good concern! It's also one we could work around with some sort of exemption list.

I'm kind of torn on that particular issue: it would be nice to allow automated filing of vulnerabilities, but at the same time some curation of the database helps keep it consistent and also catch missing details in advisories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment