Adding a crates.io Security tab #3872
Conversation
djc
added
the
T-crates-io
djc
force-pushed
the
crates-io-security
branch
from
8017e12 to
0202b53
Compare
djc
force-pushed
the
crates-io-security
branch
from
0202b53 to
80e534c
Compare
|
FYI while I'm a fan of force-pushing, I'd recommend against it for RFCs as the commits regularly get referenced. |
| are about the desirability of the feature, the implementation approach, and the governance | ||
| of the source data. | ||
|
|
||
| # Future possibilities |
There was a problem hiding this comment.
Reporting on provenance is related: https://lawngno.me/blog/2024/06/10/divine-provenance.html
The challenge there is setting the right tone of "there are divergences, this needs further investigation" rather than "this is bad!". Unsure if that can be satisfied on a Security tab, or if it needs to be a Health tab or maybe an Insights tab?
Yes, will stop doing so as I address feedback -- figured getting the RFC number in place was fine for force-pushing. |
| The RustSec advisory database is a curated database of security advisories for Rust crates, | ||
| which tracks known vulnerabilities, unsound code, and maintenance status of crates. |
There was a problem hiding this comment.
One aspect of RustSec is that it's setup to be able to issue advisories without crate author consent and potentially even when the crate author specifically asks not to. By contrast, my impression is that the project has worked hard to avoid "picking winners" or otherwise making value value judgements about crates beyond removing obvious spam/malware. There's currently a (perceived?) degree of separation between RustSec and the Rust project that enables this status quo. Displaying advisories directly on a project's crates.io page would break that.
I think there's value in empowering maintainers to notify their users that some old crate versions contain vulnerabilities. But I'm far less comfortable with having any disputed advisory becoming a permanent badge on a crate's project page or the risk of having RustSec's timelines become de-facto support SLAs that all maintainers are expected to adhere to.
Putting maintainers in control would align with open source projects (including Rust!) becoming CVE numbering authorities so that they can define what counts as a security vulnerability and control what CVEs are filed.
8 participants
Summary
This RFC proposes that crates.io should provide insight into vulnerabilities and unsound
API surface based on the RustSec advisory database.
Rendered