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.

[fintelia]

The messaging in the unsoundness/security advisories (i.e. the ones about stuff other than being unmaintained) that I've seen had much more a tone of "we're going to publish this advisory regardless, but are willing to delay a bit if you think you can get a fix out soon". In fact this policy seems to say that advisories should be published even when disputed:

If the upstream project disputes the existence of the issue, and it doesn't have a high severity, informational = "unsound" should be used

It would be a welcome change to clarify that advisories won't be filed if the crate author disputes them or asks not to.

---

Unmaintained advisories won't be displayed initially, but they've driven me to have an increasingly negative opinion of rustsec. Having a list of unmaintained crates implies that users of every other crate are entitled to prompt responses to issues or at least continued development. Which goes against the "THE SOFTWARE IS PROVIDED AS IS" that's in every OSS license. And when the typical unmaintained advisory is for some random library with approximately zero downloads/usage that's on version 0.1.2 and hasn't had a release in 8 years, it all feels rather mean-spirited to track down the original author to ask them to admit their crate is unmaintained. Doubly so if it's an employee reaching out to an unpaid volunteer. Even the terminology could've been softened to "end-of-life" which is how I've generally seen it described in commercial marketing.

[tarcieri]

You seem to be simultaneously accusing RustSec of not getting maintainer input and “track(ing) down the original author to ask them to admit their crate is unmaintained” which you call “mean spirited”.

You can’t have it both ways: to get maintainer consent on advisories we have to “track down” the maintainers and ask.

Regarding unmaintained crates, I think the recent TARmageddon vulnerability illustrates the security response problems unmaintained crates present, but also popular unmaintained libraries remain a popular target for spearphishing attacks, of which we’ve seen many recently in the npm ecosystem.

[fintelia]

Yes, I believe it is simultaneously true that there are cases where rustsec should seek (and honor) maintainer input and other cases where rustsec shouldn't consider issuing an advisory at all. Hence my qualification that that unmaintained advisories can feel mean-spirited when directed at crates with approximately zero downloads/usage.

But I think I've made my position clear and this now is sufficient off topic, so please feel free to resolve this thread.

[Turbo87]

while the point about governance seems reasonable, I think the there are still enough advantages to having it displayed on crates.io that it's worth the tradeoff.

since the discussion seems to have mostly settled:

@rfcbot fcp merge

[rust-rfcbot]

Team member @Turbo87 has proposed to merge this. The next step is review by the rest of the tagged team members:

• @0xPoe
• @LawnGnome
• @Turbo87
• @carols10cents
• @eth3lbert
• @jtgeibel
• @mdtro

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.