Adding a crates.io Security tab

[djc]

Summary

This RFC proposes that crates.io should provide insight into vulnerabilities and unsound
API surface based on the RustSec advisory database.

Rendered

[epage]

FYI while I'm a fan of force-pushing, I'd recommend against it for RFCs as the commits regularly get referenced.

[epage]

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?

[djc]

FYI while I'm a fan of force-pushing, I'd recommend against it for RFCs as the commits regularly get referenced.

Yes, will stop doing so as I address feedback -- figured getting the RFC number in place was fine for force-pushing.

[carols10cents]

In general, I'm in favor! I think this RFC could be even stronger and more compelling with a few tweaks though :)

[fintelia]

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.

[tarcieri]

RustSec has adopted an official policy around not publishing unmaintained crate advisories if the owner advises against it, and to my knowledge we've never published a security advisory the owner disagrees with, though we can perhaps codify that as a more official policy. Generally we like to get advice from crate owners/authors whenever possible when publishing advisories, which is something lacking in other vulnerability reporting mechanisms.

The flipside is there are many abandoned crates with unresponsive authors, and we'd like to avoid a scenario where we can't publish advisories around those because we haven't gotten express owner consent.