If yank would want to satisfy all those usecases, it IMO would have to change such that, by default, it only ever prints warnings about yanked crates, and never refuses to compile. In particular “refuse to compile added dependencies if those are yanked” is problematic for security vulnerabilities, but an absolute no-starter for some of the other yank reasons you listed.
I’d say such semantics are toothless. Even with the new output format you propose I feel like all the user sees at a glance is a giant wall of yellow at the end of the output, because if yank is extended for deprecating packages for all kinds of reasons, there sure is going to be a lot of that.
You could then add options to make certain classes of yanks hard errors and suppress others, but I feel like those options are more likely to be abused than allow_vulnerable.
True! This is executed pretty rarely, though, and I imagine we could solve the issue by making it easy to execute the command multiple times?
The lack of support on Windows (this will basically never work) makes me think that we shouldn't try to optimize this use case. It means many users will not have an editor opened automatically, so we shouldn't optimize for that.
True yeah, but I think the risk is still there. If a user once or twice starts seeing vulnerabilities they have no idea how to fix, then one might quickly enter the mode of "just always ignore" the messages.
I would prefer the reverse, an option to turn warnings to errors. I personally feel that breaking existing builds with a Cargo.lock, for whatever reason, is a non-starter.
Oh I just mean cargo publish --allow-vulnerable or something like that rather than modifying Cargo.toml.
There is another drawback: Some crate developers may not be aware of this mechanism and/or may be aware of it and choose not to use it for various reasons. Further, the cost is too expensive to keep track of vulnerabilities in every version of a crate ever published, to minimize costs it makes sense to mark everything but the newest version vulnerable, or abstain from using the mechanism at all.
Thus, while the existence of the mechanism would likely induce people to depend on it, but it isn't something people can depend on and it would create a false sense of security.
Which is why I wanted to use hard errors for security vulnerabilities during testing, such that they're harder to ignore and people rather ask questions than ignore.
That's what I said.
see here for why having a bool switch for turning off all vulnerability warnings is highly problematic. My version to disable them on a per-dependency basis is already argued to be too broad, yours is broader.
For "lazier" developers this is exactly the behavior I want to nudge them into rather than not using the feature at all, by defaulting to selecting all versions by default. The idea is that you'd release a new patched version after marking all existing versions as vulnerable.
Regarding developers that simply won't use this due to other reasons, I can't think of an alternative design that solves this problem, but it's surely worth mentioning as drawback. FIXME
Nobody should be (newly!) depending on a crate with known sec vulnerabilities
A crate can be big and abandoned.
Big means a vulnerability can affect only small portion of it which is not used by an application (including new applications). So application author may decide to suppress this individual vulnerability.
Abandoned means there is no newer version without vulnerability (and the advisory may be actually created by some third party). It does not also mean there is non-abandoned successor.