A unique, descriptive title (so no more “Security advisory for the standard library”, please)
Perhaps a Rust-specific identifying number (perhaps the matching Rust version number, if security announcements always come with a new Rust release)
A link to one or more Git commits fixing the vulnerability
The last item is perhaps the most important one because in the absence of other identifiers, the fix itself almost always makes it absolutely clear what you are talking about.
(It would be nice to get a CVE ID prior to disclosure, but I don’t know what the current politics are, or if there are any challenges there at all.)
Regarding CVE IDs, as Rust is not a project of any of the CVE corporate numbering authorities (Mozilla supports Rust substantially, but I don’t believe Rust issues would fall under Mozilla’s aegis as a numbering authority), requests for a CVE ID would likely have to go through the Distributed Weakness Filing Project, which is the numbering authority for all FOSS not covered by another NA.
Even if the CVE system is not used (is there precedence for using it in other programming language projects), some numbering system seems worthwhile. Enabling exact reference to security vulnerabilities can do a lot to clarify discussions, particularly as Rust ages.
In the crate ecosystem, the RustSec team has been maintaining such a numbering list, but right now it doesn’t cover the standard library.
Yeah, sorry, “have to go” was too strong. MITRE is the numbering authority of last resort, and so generally I believe it is more technically correct to go through the Distributed Weakness Filing Project.
We will take this under consideration, thanks. You're right, but
When filing a CVE, if there's no embargo, they ask for URLs of the announcement to point to for more information. So generally, you get a CVE post announcement. I hear you though.
Yep!
That is how Alex and I file for them, yes.
Incidentally I still have not yet heard back for this latest one.
We discussed this on the Security WG kickoff call, and there's also an open RustSec issue about it:
I think ideally RustSec could track vulnerabilities for the standard library and assign them a RUSTSEC-* advisory. I'd definitely recommend every one of these vulnerabilities have a CVE as the canonical identifier (so as to better integrate with e.g. Linux distro package managers and vulnerability reporting). I can (re)apply for a CVE block for RustSec (we still need to assign CVEs to all existing RUSTSEC vulnerabilities) and we can assign out of that pool.
I definitely think this is very important. I would like to be able to e.g. compare the Rust compiler version tagged on build artifacts against a vulnerability database so as to determine if any of them were built with a vulnerable compiler.
For final build artifacts (executables, as well as some other formats in the case of embedded, wasm, FFI, ...), agreed! (For intermediate build artifacts (libs and stuff cached under target/ in a workspace), I expect nothing special should be needed: a new compiler of any kind shouldn't match/use old artifacts and cargo will rebuild dependencies).
As a tangential illustration, the cargo-update crate contains a cargo addon command install-update that deals with updating binaries installed with cargo install when their corresponding source crates change. There's also an option to force-rebuild everything, which I'll sometimes do for example when the compiler has changed, "just because". It would be great if 'was built with vulnerable components' could also trigger such a rebuild.
This isn't so much a feature request for that crate specifically, as for the surrounding infrastructure that publishes the data to enable such decisions by tooling generally.
There's also maybe some scope opportunity/discussion to settle: an expansion of "vulnerable components" to include ecosystem crate tags (using cargo audit data), and maybe some slightly broader set of important compiler+std updates that probably also include some really significant features, performance changes, soundness-but-not-security fixes.
As a smallest possible starting point: is there a crate today to analyse build artifacts and extract the relevant metadata about compiler and dependency versions, or to abstract over many possible platform formats to do so? Is there some machine-independent metadata blob that rustc can embed (in a platform-specific way), so that the format layer only has to know how to find the blob?
@alilleybrinker, a source close to the DFW project just told me that it seems to be inactive, and that specific pull requests haven’t been approved for almost a month. You should cancel your request to DFW and fill out the MITRE form instead.