Whenever I have time I’ll rewrite the RFC to extend yanking instead, it seems to be a much more popular option.
The RFC does not say anything about who could flag a crate as vulnerable. I guess it is implied that only the crate author can do it. However, it might be good to consider an alternative way for the (not unlikely) case in which an abandoned but commonly used crate is found vulnerable. A possibility would be that a group of people appointed by the core devs have permissions on crates.io to flag a crate as vulnerable. I understand that some would not like this for being invasive but I think it could be a good thing overall if it is done transparently.
I’ll clarify this. I think intervention by “crates.io mods” in general doesn’t require an RFC and will happen anyway.
I think when formulated this way, there are actually two proposals that might as well be split in two RFCs:
- Adding extended, structured metadata to yanked crates
- Changing Cargo’s behavior for yanked crates to allow using
yank-ing for security announcements
Which of those even warrants a RFC?
I suppose one RFC would be enough particularly because it most likely will have to explain how to silence individual security warnings explicitly (would that go into Cargo.toml?)
Shall it also extend to non-security serious bugs that can lead to data loss?
Absolutely not. I don’t want to duplicate a bugtracker into Crates.io.
Getting a CVE issued is not guaranteed. Anything “out of scope” will not get one, and so blocking use of this feature on a 3rd party seems troublesome.
I would suggest using DWF instead of CVE:
DWF was created by the guy who runs https://iwantacve.org/ to distributed the administrative overhead of acquiring CVEs.
All CVEs are valid DWFs, and a CVE can be converted into a DWF by doing s/CVE/DWF/. DWF can be thought of as a superset of the CVE space.
With DWF, https://crates.io could apply for a block of DWF identifiers, and automatically assign them when someone does cargo vuln (or, as I'd now personally prefer, cargo advisory). Or, crates that do get a CVE assigned can use that instead, but translating it to a DWF first.
As a separate issue, I would suggest NOT coupling security advisories to yanks. Yanks are extremely disruptive and not all vulnerabilities are created equal. Some vulnerabilities can be mitigated in ways other than upgrading a crate, like making local configuration changes. Some vulnerabilities may affect optional functionality not everyone is using or functionality that can be compiled out by e.g. disabling certain cargo feature settings for that crate. Some may be relatively innocuous and/or hard-to-exploit and therefore not warrant an immediate upgrade.
Advisories are just that: they should give advice on how to deal with an issue, without breaking your program and forcing an upgrade. I would argue that coupling this sort of functionality to yanks would severely diminish its utility to a point of near-uselessness.
I would suggest a well-considered second step after any sort of cargo vuln / cargo advisory feature ships could be to include something like a vulnerability class, severity, CVSS score, etc that people could potentially gate hard failures on (e.g. in CI). But I don’t think forcing a yank for any sort of security vulnerability you plan on issuing an advisory for makes sense.
2 Likes
Yanks shouldn’t be extremely disruptive, as they don’t cause existing projects to not fetch that dep, only new ones, right?
(I still agree that coupling the two may not be the best idea, exactly.)
I think this isn't a good reason for not using CVE numbers. CVE numbers are already used by C/C++ projects and various projects that use memory-safe languages. Rust's safety properties should result in fewer vulnerabilities per line of code per time than C or C++, and the Rust ecosystem is still smaller.
Therefore, Crates.io using CVE numbers would get nowhere near even a single order of magnitude (times 10) increase--not even doubling the CVE issuing rate.
I think the only reason not to use CVE numbers would be the inability to get them assigned in an automated fashion. I have zero experience on that front, but on surface, what @bascule says about DWF seems promising.
I general, I think it would be very valuable to integrate security advisories into crates.io metadata.
It's not about how many vulnerabilities there are but how many get CVE numbers. The vulnerabilities are a few orders of magnitude higher than issued CVEs.
1 Like
What about assigning DWF numbers automatically and letting the user optionally (and manually) specify a CVE number? This would result in two DWF numbers though.
I myself have no opinion on whether to use DWF or CVE but I would agree that assigning CVEs in an automated manner is not possible.
Also I want to post a pre-RFC soon-ish. Some important questions where I’m unclear about the consensus:
- vuln as separate command or integrated into yank?
- Simple warning for compiling crates with advisories, or refusal unless overridden in Cargo.toml (see current RFC draft for details)?
- Automated DWF filing, and/or optional DWF, and/or optional CVE?
- Vulnerability scoring integrated into Crates.io?
My vote:
- separate command instead of colluded with yank
- warn by default with optional hard failure
- store a DWF ID for each vuln. Obtaining one automatically if one isn’t passed in explicitly is gravy.
- I would postpone any sort of severity scoring in the initial implementation. The existing methods (e.g. CVSS) are somewhat lousy and I’m worried trying to do anything else will turn into a giant bikeshedding debate. If people really have their hearts set on CVSS(v3), I wouldn’t be opposed though.
warn by default with optional hard failure
Where would this option be? Something like #[deny(security_advisories)] or within Cargo.toml? Or just as a CLI option? I suspect that the former isn't doable since that sort of metadata is not available anymore at compile time.
store a DWF ID for each vuln. Obtaining one automatically if one isn't passed in explicitly is gravy.
Oh that makes sense, I'd vote for this too.
(TIL what gravy means in this context: optional)
Anybody else?
I’ve posted a pre-RFC at [pre-RFC] Security advisories as part of crates.io metadata, please continue discussion there.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.