From 80e534cf4ba357c3048d6957373f5d44b8b5e80f Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Mon, 6 Oct 2025 13:55:13 +0200 Subject: [PATCH 1/8] Initial draft for crates-io-security --- text/3872-crates-io-security.md | 130 ++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 text/3872-crates-io-security.md diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md new file mode 100644 index 00000000000..841402e6792 --- /dev/null +++ b/text/3872-crates-io-security.md @@ -0,0 +1,130 @@ +- Feature Name: crates-io-security +- Start Date: 2025-10-27 +- RFC PR: [rust-lang/rfcs#3872](https://github.com/rust-lang/rfcs/pull/3872) +- Rust Issue: [rust-lang/rust#3872](https://github.com/rust-lang/rust/issues/3872) + +# Summary +[summary]: #summary + +This RFC proposes that crates.io should provide insight into vulnerabilities and unsound +API surface based on the RustSec advisory database. + +# Motivation +[motivation]: #motivation + +One of the roles that crates.io serves for Rust developers is as a discovery mechanism for library +packages. As such, it is important that users can quickly assess the quality of a given crate, +including security considerations such as unsound code/API or known vulnerabilities. +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. + +The Rust ecosystem has a culture of having smaller, focused crates with a clear purpose. +As a result, many Rust projects have a large number of dependencies, which increases the +risk of introducing problems in the final artifact via the supply chain of dependencies. + +We've seen an increasing number of security issues via transitive dependencies: + +* In 2024, some releases of the popular xz-utils package (written in C) contained + a [malicious backdoor] affecting OpenSSH servers running on the local system. +* In 2025, a phishing campaign [targeted crates.io users] using the `rustfoundation.dev` domain + name to impersonate the Rust Foundation and steal maintainer's credentials. + +While known actively malicious crates would be deleted from crates.io by the responsible team, +unintentional vulnerabilities and unsound APIs can still pose a risk to Rust developers. + +The Open Source Security Foundation (OpenSSF) has enumerated [Principles for Package Repository +Security]; while crates.io already addresses many of these, one of these is: + +> The package repository warns of known security vulnerabilities in dependencies in the package +> repository UI. + +The RustSec advisory database tooling already supports exporting advisories in the OSV format. + +[malicious backdoor]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor +[targeted crates.io users]: https://blog.rust-lang.org/2025/09/12/crates-io-phishing-campaign/ +[Principles for Package Repository Security]: https://repos.openssf.org/principles-for-package-repository-security.html + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +The crates.io website will display information about known vulnerabilities and unsound APIs. +This might take the form of a Security tab on a crate's page. If there are known vulnerabilities +for the currently selected version, the tab might be highlighted. The Security tab will be +there whether there are existing advisories for a crate or not, and the linked page will show +a message indicating that there are no published advisories if that is the case. + +Opening the Security tab for a crate should show a list of advisories that affect the crate, +including a summary of the issue, a list of affected versions, and links to more information. +Care should be taken to ensure that the mere existence of past vulnerabilities does not negatively +impact the perceived quality of a crate; very popular crates are much more likely to have +vulnerabilities reported against them, simply due to their popularity and the amount of scrutiny. + +The Security tab should give Rust developers a quick overview of the security status of a crate, +and allow them to make informed decisions about whether to use the crate in their projects. + +While this information is available today via the RustSec website (including feeds that can +automatically be consumed by tooling), having this information directly on crates.io would +make it accessible and visible to a wider audience. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +The RustSec project publishes a number of Rust crates that can be used to parse and query the +advisory database, which can be reused in the crates.io codebase. For now, crates.io will only +display advisories in the UI; we will not be adding API to query RustSec advisories. Downstream +users who want to consume this data can use the RustSec crates and the [advisory-db repository] +directly. + +[advisory-db repository]: https://github.com/RustSec/advisory-db + +# Drawbacks +[drawbacks]: #drawbacks + +The RustSec project is maintained by an independent team of volunteers, so the crates.io Security +tab will be reflecting data that is maintained by what amounts to a kind of third party. +The Leadership Council has an [ongoing discussion] on governance for the Secure Code WG that +governs the RustSec project, which might be relevant to this proposal. + +Rust developers might be scared off of using crates that have known vulnerabilities, even if +those vulnerabilities are not relevant to their use case, or have been fixed in later versions. +This seems like a reasonable trade-off to me -- we should allow informed users to make decisions +that are best for their projects. + +[ongoing discussion]: https://github.com/rust-lang/leadership-council/issues/140 + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +crates.io is the official package repository for the Rust ecosystem, so sharing important security +context via this interface seems like an effective way to make it accessible to a wide audience. + +Widely used tools like [cargo-audit] and [cargo-deny] already provide a way to check for +security-sensitive issues in a Rust project's dependencies, but these tools are opt-in and require +users to be aware of them and to run them. They are also more focused on auditing a project's +existing dependencies rather than helping inform users in the discovery phase. + +Alternatively, we might make the RustSec advisory database available directly via cargo. This +seems mostly unrelated to what crates.io does, and seems like an interesting future possibility. + +[cargo-audit]: https://crates.io/crates/cargo-audit +[cargo-deny]: https://crates.io/crates/cargo-deny + +# Prior art +[prior-art]: #prior-art + +Neither npm nor PyPI currently seem to provide support for displaying security advisories. + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +This seems like a relatively straightforward feature with a limited scope. The main questions +are about the desirability of the feature, the implementation approach, and the governance +of the source data. + +# Future possibilities +[future-possibilities]: #future-possibilities + +In the future, it would be valuable if lockfile updates exposed open vulnerabilities in a +project's dependency graph in the Cargo CLI, for example on `cargo update` or `cargo check`. + +crates.io could extend its existing API to query advisories for a given crate. From d75a3e039bc17c4b91ad0cb37a3aa42802b1f723 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Tue, 28 Oct 2025 14:01:52 +0100 Subject: [PATCH 2/8] Appease VS Code formatting --- text/3872-crates-io-security.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index 841402e6792..c2ff0f2994f 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -4,12 +4,14 @@ - Rust Issue: [rust-lang/rust#3872](https://github.com/rust-lang/rust/issues/3872) # Summary + [summary]: #summary This RFC proposes that crates.io should provide insight into vulnerabilities and unsound API surface based on the RustSec advisory database. # Motivation + [motivation]: #motivation One of the roles that crates.io serves for Rust developers is as a discovery mechanism for library @@ -24,9 +26,9 @@ risk of introducing problems in the final artifact via the supply chain of depen We've seen an increasing number of security issues via transitive dependencies: -* In 2024, some releases of the popular xz-utils package (written in C) contained +- In 2024, some releases of the popular xz-utils package (written in C) contained a [malicious backdoor] affecting OpenSSH servers running on the local system. -* In 2025, a phishing campaign [targeted crates.io users] using the `rustfoundation.dev` domain +- In 2025, a phishing campaign [targeted crates.io users] using the `rustfoundation.dev` domain name to impersonate the Rust Foundation and steal maintainer's credentials. While known actively malicious crates would be deleted from crates.io by the responsible team, @@ -45,6 +47,7 @@ The RustSec advisory database tooling already supports exporting advisories in t [Principles for Package Repository Security]: https://repos.openssf.org/principles-for-package-repository-security.html # Guide-level explanation + [guide-level-explanation]: #guide-level-explanation The crates.io website will display information about known vulnerabilities and unsound APIs. @@ -67,6 +70,7 @@ automatically be consumed by tooling), having this information directly on crate make it accessible and visible to a wider audience. # Reference-level explanation + [reference-level-explanation]: #reference-level-explanation The RustSec project publishes a number of Rust crates that can be used to parse and query the @@ -78,6 +82,7 @@ directly. [advisory-db repository]: https://github.com/RustSec/advisory-db # Drawbacks + [drawbacks]: #drawbacks The RustSec project is maintained by an independent team of volunteers, so the crates.io Security @@ -93,6 +98,7 @@ that are best for their projects. [ongoing discussion]: https://github.com/rust-lang/leadership-council/issues/140 # Rationale and alternatives + [rationale-and-alternatives]: #rationale-and-alternatives crates.io is the official package repository for the Rust ecosystem, so sharing important security @@ -110,11 +116,13 @@ seems mostly unrelated to what crates.io does, and seems like an interesting fut [cargo-deny]: https://crates.io/crates/cargo-deny # Prior art + [prior-art]: #prior-art Neither npm nor PyPI currently seem to provide support for displaying security advisories. # Unresolved questions + [unresolved-questions]: #unresolved-questions This seems like a relatively straightforward feature with a limited scope. The main questions @@ -122,6 +130,7 @@ are about the desirability of the feature, the implementation approach, and the of the source data. # Future possibilities + [future-possibilities]: #future-possibilities In the future, it would be valuable if lockfile updates exposed open vulnerabilities in a From 2bc2a4516a47055465626e273968cd9b2a8cd457 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Tue, 28 Oct 2025 14:38:39 +0100 Subject: [PATCH 3/8] Attempt better separation of goals and proposed UI --- text/3872-crates-io-security.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index c2ff0f2994f..d8b17e9bbe7 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -51,24 +51,25 @@ The RustSec advisory database tooling already supports exporting advisories in t [guide-level-explanation]: #guide-level-explanation The crates.io website will display information about known vulnerabilities and unsound APIs. -This might take the form of a Security tab on a crate's page. If there are known vulnerabilities -for the currently selected version, the tab might be highlighted. The Security tab will be -there whether there are existing advisories for a crate or not, and the linked page will show -a message indicating that there are no published advisories if that is the case. - -Opening the Security tab for a crate should show a list of advisories that affect the crate, -including a summary of the issue, a list of affected versions, and links to more information. -Care should be taken to ensure that the mere existence of past vulnerabilities does not negatively -impact the perceived quality of a crate; very popular crates are much more likely to have -vulnerabilities reported against them, simply due to their popularity and the amount of scrutiny. - -The Security tab should give Rust developers a quick overview of the security status of a crate, -and allow them to make informed decisions about whether to use the crate in their projects. - While this information is available today via the RustSec website (including feeds that can automatically be consumed by tooling), having this information directly on crates.io would make it accessible and visible to a wider audience. +We want to convey a quick overview of the security status of a crate, and allow users to make informed decisions about whether to use the crate in their projects. Care should be taken to +ensure that the mere existence of past vulnerabilities does not negatively impact the perceived quality of a crate; very popular crates are much more likely to have vulnerabilities reported +against them, simply due to their popularity and the amount of scrutiny. + +For example, the UI could be somewhat like this: + +> Add a `Security` tab to crate pages. If there are known vulnerabilities for the currently +> selected version, the tab might be highlighted. The Security tab will be there whether there +> are existing advisories for a crate or not. Opening the Security tab for a crate should show +> a list of advisories that affect the crate, including a summary of the issue, a list of +> affected versions, and links to more information. + +The way advisories are represented in the crates.io UI will evolve over time based on the +available data and user feedback. This RFC does not mandate a specific UI design. + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 4eb1e35ee349d015cfce6070399710a67572d4b3 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Tue, 28 Oct 2025 14:46:09 +0100 Subject: [PATCH 4/8] Add lib.rs audit pages as prior art --- text/3872-crates-io-security.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index d8b17e9bbe7..6fdac153374 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -122,6 +122,14 @@ seems mostly unrelated to what crates.io does, and seems like an interesting fut Neither npm nor PyPI currently seem to provide support for displaying security advisories. +[lib.rs], the opinionated alternative crate index, does have an [audit page] that shows +both RustSec advisories and reviews from [cargo-crev] and [cargo-vet]. + +[lib.rs]: https://lib.rs/ +[audit page]: https://lib.rs/crates/tokio-tar/audit +[cargo-crev]: https://github.com/crev-dev/cargo-crev +[cargo-vet]: https://github.com/mozilla/cargo-vet + # Unresolved questions [unresolved-questions]: #unresolved-questions From 83214f117351ce48caadd6714a27b54835db0ed0 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Tue, 28 Oct 2025 14:47:50 +0100 Subject: [PATCH 5/8] Add note on sending feedback to RustSec --- text/3872-crates-io-security.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index 6fdac153374..586d52d159b 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -89,7 +89,8 @@ directly. The RustSec project is maintained by an independent team of volunteers, so the crates.io Security tab will be reflecting data that is maintained by what amounts to a kind of third party. The Leadership Council has an [ongoing discussion] on governance for the Secure Code WG that -governs the RustSec project, which might be relevant to this proposal. +governs the RustSec project, which might be relevant to this proposal. Feedback on the RustSec +advisory data can be fed back to the RustSec team via their issue tracker. Rust developers might be scared off of using crates that have known vulnerabilities, even if those vulnerabilities are not relevant to their use case, or have been fixed in later versions. From 09f2a1f891ea74935ced4879d1633ba3b4305f97 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Mon, 3 Nov 2025 11:34:52 +0100 Subject: [PATCH 6/8] Clarify difference between malicious and unintentional issues --- text/3872-crates-io-security.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index 586d52d159b..977f530d7c1 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -23,16 +23,12 @@ which tracks known vulnerabilities, unsound code, and maintenance status of crat The Rust ecosystem has a culture of having smaller, focused crates with a clear purpose. As a result, many Rust projects have a large number of dependencies, which increases the risk of introducing problems in the final artifact via the supply chain of dependencies. +Actively malicious crates (or crate versions) would be one example of these risks; the +crates.io team handles these by deleting them when discovered. -We've seen an increasing number of security issues via transitive dependencies: - -- In 2024, some releases of the popular xz-utils package (written in C) contained - a [malicious backdoor] affecting OpenSSH servers running on the local system. -- In 2025, a phishing campaign [targeted crates.io users] using the `rustfoundation.dev` domain - name to impersonate the Rust Foundation and steal maintainer's credentials. - -While known actively malicious crates would be deleted from crates.io by the responsible team, -unintentional vulnerabilities and unsound APIs can still pose a risk to Rust developers. +This RFC concerns itself mostly with unintentional vulnerabilities and unsound APIs. An example +from the Java ecosystem is the [Log4Shell] vulnerability in the popular Log4j logging library, +when a widely used package exposed affected services to remote code execution attacks. The Open Source Security Foundation (OpenSSF) has enumerated [Principles for Package Repository Security]; while crates.io already addresses many of these, one of these is: @@ -42,8 +38,7 @@ Security]; while crates.io already addresses many of these, one of these is: The RustSec advisory database tooling already supports exporting advisories in the OSV format. -[malicious backdoor]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor -[targeted crates.io users]: https://blog.rust-lang.org/2025/09/12/crates-io-phishing-campaign/ +[Log4Shell]: https://en.wikipedia.org/wiki/Log4j#Log4Shell_vulnerability [Principles for Package Repository Security]: https://repos.openssf.org/principles-for-package-repository-security.html # Guide-level explanation From 8621245d70659eb6813bdee566df0ebbd8e79742 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Mon, 3 Nov 2025 11:46:23 +0100 Subject: [PATCH 7/8] Clarify goals with single crate vs dependencies --- text/3872-crates-io-security.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index 977f530d7c1..ecae8b6f03b 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -37,6 +37,9 @@ Security]; while crates.io already addresses many of these, one of these is: > repository UI. The RustSec advisory database tooling already supports exporting advisories in the OSV format. +Today, crates.io does not display any information about known vulnerabilities or unsound APIs +for a given crate. Devising how best to surface this information across a project dependency +graph is a more complex problem that is outside the scope of this RFC (but see future work). [Log4Shell]: https://en.wikipedia.org/wiki/Log4j#Log4Shell_vulnerability [Principles for Package Repository Security]: https://repos.openssf.org/principles-for-package-repository-security.html @@ -140,5 +143,7 @@ of the source data. In the future, it would be valuable if lockfile updates exposed open vulnerabilities in a project's dependency graph in the Cargo CLI, for example on `cargo update` or `cargo check`. +crates.io doesn't necessarily have good access to a project's dependency graph, so a simple +implementation would be limited to direct dependencies, which limits its usefulness. crates.io could extend its existing API to query advisories for a given crate. From 1f931f5a8f03b0a5e6da13fdb83ab93968287440 Mon Sep 17 00:00:00 2001 From: Dirkjan Ochtman Date: Mon, 3 Nov 2025 11:46:37 +0100 Subject: [PATCH 8/8] Add future work section on SECURITY.md files --- text/3872-crates-io-security.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/3872-crates-io-security.md b/text/3872-crates-io-security.md index ecae8b6f03b..e8e68853c42 100644 --- a/text/3872-crates-io-security.md +++ b/text/3872-crates-io-security.md @@ -147,3 +147,9 @@ crates.io doesn't necessarily have good access to a project's dependency graph, implementation would be limited to direct dependencies, which limits its usefulness. crates.io could extend its existing API to query advisories for a given crate. + +`SECURITY.md` files are often used to communicate a project's security policies. crates.io +could surface the contents of these files on the new Security page. However, `SECURITY.md` +files commonly live in the repository root, which is often a crate workspace, and thus +is not directly associated with a specific crate. Some prerequisite work in Cargo would +probably be needed to associate a crate with the relevant `SECURITY.md` file.