# About release dead code crates **URL:** \ **Category:** Uncategorized\ **Created:** [March 19, 2022, 2:51pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350 "2022-03-19T14:51:40Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![zhuxiujia](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/zhuxiujia/32/7498_2.png) [@zhuxiujia](https://internals.rust-lang.org/u/zhuxiujia)\ **Post date:** [March 19, 2022, 2:51pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/1 "2022-03-19T14:51:40Z")
Mail queries are made for crates that have not been maintained for at least 2 years, and if there is no response, the library is deleted and released. This prevents someone from taking the name and not using it ---
**Author:** ![elidupree](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elidupree/32/4304_2.png) [@elidupree](https://internals.rust-lang.org/u/elidupree)\ **Post date:** [March 19, 2022, 2:56pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/2 "2022-03-19T14:56:13Z")
This has been discussed before, and a major problem is that if anyone has a dependency on the deleted crate, it not only breaks their code, but also allows supply-chain attacks where a malicious user creates a new, malicious crate with the same name as the deleted one. ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [March 19, 2022, 3:09pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/3 "2022-03-19T15:09:35Z")
For what it's worth, we track unmaintained crates in the RustSec Security Advisory Database: > **[About RustSec › RustSec Advisory Database](https://rustsec.org)** > > Security advisory database for Rust crates published through https://crates.io ---
**Author:** ![ChrisJefferson](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/chrisjefferson/32/4766_2.png) [@ChrisJefferson](https://internals.rust-lang.org/u/ChrisJefferson)\ **Post date:** [March 19, 2022, 9:21pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/4 "2022-03-19T21:21:03Z")
What does "maintained" mean? While Rust isn't old enough yet, I've worked with libraries in C which haven't had an update in 10 years, as they are just "done". ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [March 19, 2022, 9:36pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/5 "2022-03-19T21:36:40Z")
You can review the WIP guidance we're crafting on that topic here: > > > Initial guide on policy around what RustSec considers to be an unmaintained crat…e as well as the policy for filing an advisory. > > This has come up / been requested often enough I thought I'd finally take a go at writing something up. > > \[Rendered\](https://github.com/rustsec/advisory-db/blob/024202565812a765d3b02f32f74c08475689ac14/HOWTO\_UNMAINTAINED.md) tl;dr: crates where the author agrees it's unmaintained, or crates with non-communicative authors which are not receiving any updates/releases/etc ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [March 22, 2022, 2:01pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/6 "2022-03-22T14:01:43Z")
The supply-chain problem can be solved by allowing new maintainers only release a higher semver-major version. So if a crate stopped being maintained at v3.3.0, the new owner can only release v4.0.0, but not 3.3.1 nor 2.0.0. In typical usage this will prevent other users from automatically upgrading to a potentially-malicious crate. There can also be a required period in between when the crate is completely yanked and unusable, so that its active users will notice and remove the dead dependency. ---
**Author:** ![ckaran](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@ckaran](https://internals.rust-lang.org/u/ckaran)\ **Post date:** [March 22, 2022, 3:28pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/7 "2022-03-22T15:28:53Z")
What about a scheme using digital signatures? AFAIK, crate repositories (including `crates.io`) match based on the name of the crate alone. Given that, we can have the following scheme: 1. When an author makes a release, they sign two documents. The first is a UTF-8 encoded plain text file containing the canonical name of the crate only. This is the exact name that you would use in your `Cargo.toml` file, and anywhere else that is mechanically verified or used. The second is the complete material that is being released, which **must** be signed with the same key. 2. When you download a crate, you get both of these files, plus the keys to verify the signature. The verifying keys are put in your `Cargo.lock` file, or in `.cargo`, or wherever it's best to place it. 3. When you build a crate, `cargo` verifies that signatures on both files is good, complaining loudly if the signatures on either are bad. **It will also do this if it already has key material on file for that crate.** For someone to replace a well-known crate, they have to get people to accept the new keys before their replacement crate will be built and incorporated. I think that this will require minimal changes. Basically, a new file (`CrateRepositoryName.txt`? Someone bikeshed this) that the crate author will need to sign before upload, and maybe some work on the crate repositories end to reject releases that don't have this file. After that, it becomes a matter of educating people, and eventually releasing the names of dead crates. I think that the following table outlines the possible outcomes of good/bad signatures: | Name File | Complete Material in Release | Keys matching | Result | | --- | --- | --- | --- | | Good signature | Good signature | Matches original | Good crate, carry on | | Good signature | Good signature | Doesn't match original | Maybe a new maintainer? Verify before use. | | Good signature | Bad signature | Matches original | Corrupted crate, use a different version, contact author. | | Good signature | Bad signature | Doesn't match original | Supply chain attack! Report to [rustsec](https://rustsec.org/) ASAP! | | Bad signature | Good signature | Matches original | Corrupted crate, use a different version, contact author. | | Bad signature | Good signature | Doesn't match original | Supply chain attack! Report to [rustsec](https://rustsec.org/) ASAP! | | Bad signature | Bad signature | Matches original | Supply chain attack! Report to [rustsec](https://rustsec.org/) ASAP! (implies `crates.io` was hacked) | | Bad signature | Bad signature | Doesn't match original | See below | In the last line, if the signatures are bad and the keys don't match the original then there are a couple of possibilities. First, the author may have updated their keys, but forgotten to update `crates.io` with the new keys. Report it as a bug to the author, and see if they put out a new release shortly. Note that it would be good practice for crate authors to keep the contents of new release identical to the old release, while just updating their keys; this lets automated tools verify that this was just an honest mistake as the contents of the release will remeain the same. The other possibility is that someone is trying to do a supply chain attack, but has done a really, really bad job of it. Report it to [rustsec](https://rustsec.org/), so that they can see if there is anything that can/should be done. I think that [crates.io](http://crates.io) can automatically triage some of the above. For those parts that are highly likely to be supply chain attacks, it could even report to [rustsec](https://rustsec.org/) automatically. ---
**Author:** ![amosonn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/amosonn/32/7676_2.png) [@amosonn](https://internals.rust-lang.org/u/amosonn)\ **Post date:** [March 24, 2022, 9:15pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/8 "2022-03-24T21:15:48Z")
In that case, there's no real need to yank at all. The old versions can stay available for download, if the problem is just hogging the name and not the storage required. This might be confusing if the two crates would share the same landing page, so it would be better to add [crates.io](http://crates.io) support for multiple pages of the same crate. However if the assumption is that the old crate is dead, findability of it is less important. ---
**Author:** ![alilleybrinker](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alilleybrinker/32/11576_2.png) [@alilleybrinker](https://internals.rust-lang.org/u/alilleybrinker)\ **Post date:** [March 28, 2022, 7:46pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/9 "2022-03-28T19:46:24Z")
Getting people to manage keys correctly is really difficult. Even when they're strongly motivated to do so. People still lose keys to access cryptocurrency wallets worth large amounts of money. Getting people to actually think about whether to accept or reject updated keys for their counterparties rather than blindly accept updated keys is even harder. Adding key management to things needs to be thought about extremely carefully for usability, because otherwise you get a lot of friction for little real-world benefit. ---
**Author:** ![ckaran](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@ckaran](https://internals.rust-lang.org/u/ckaran)\ **Post date:** [March 28, 2022, 8:04pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/10 "2022-03-28T20:04:56Z")
I agree that getting people to manage their keys correctly is difficult. But I also think that it's the best way to deal with this problem. Supply chain attacks are real, and as rust gets to be bigger, it will become a bigger target to attack. Crypto is probably going to be the only realistic way of dealing with it... ---
**Author:** ![alilleybrinker](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alilleybrinker/32/11576_2.png) [@alilleybrinker](https://internals.rust-lang.org/u/alilleybrinker)\ **Post date:** [March 29, 2022, 11:08pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/11 "2022-03-29T23:08:36Z")
I agree that supply chain attacks are a real problem. However, saying "something must be done" isn't the same as "this specific thing must be done." The problem in this case is one of trusting software artifacts. The [SLSA](https://slsa.dev) and [SCITT](https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture-00.html) standards which are developing (building off of COSE and in-toto) are a more compelling and complete solution to this problem that one that the Rust community could device independently. ---
**Author:** ![ckaran](https://avatars.discourse-cdn.com/v4/letter/c/f475e1/32.png) [@ckaran](https://internals.rust-lang.org/u/ckaran)\ **Post date:** [March 30, 2022, 1:06pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/12 "2022-03-30T13:06:28Z")
> [@alilleybrinker](#): > > I agree that supply chain attacks are a real problem. However, saying "something must be done" isn't the same as "this specific thing must be done." I agree 100% with this. I misunderstood what you were saying; I thought that you were saying that because keys are difficult to manage, we should give up trying to solve the problem in a robust manner. > [@alilleybrinker](#): > > The problem in this case is one of trusting software artifacts. The [SLSA](https://slsa.dev) and [SCITT](https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture-00.html) standards which are developing (building off of COSE and in-toto) are a more compelling and complete solution to this problem that one that the Rust community could device independently. Thank you, I didn't know about those at all! Have you brought these to the attention of the [rust secure code working group](https://www.rust-lang.org/governance/wgs/wg-secure-code)? As you say, they are much more complete standards than what we're discussing here. ---
**Author:** ![alilleybrinker](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alilleybrinker/32/11576_2.png) [@alilleybrinker](https://internals.rust-lang.org/u/alilleybrinker)\ **Post date:** [March 31, 2022, 2:38pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/13 "2022-03-31T14:38:09Z")
I have now raised these in the Rust secure code working group Zulip channel. Thanks! ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [April 4, 2022, 4:31pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/14 "2022-04-04T16:31:18Z")
Speaking on behalf of the Rust Secure Code Working Group, we have been following and participating in various in-toto discussions for several years. Adding anything like that to cargo itself seems rather tricky though. We've had a few issues open about that for several years: > > > The fun thing about packaging systems with central package directories is the ce…ntral package directories have this annoying tendency to be compromised. There have been a few such notable compromises in recent history, such as RubyGems and npm. Fortunately no serious problems resulted in either of these attacks they were both detected early, but a more sinister attack could go undetected, poisoning the package repository and spreading malware. > > One way to stop this is to move the source of authority for the integrity of packages from the package repository to the developers of packages. However, managing keys is hard, and many people simply won't want to do this. Furthermore, you have to worry about how to retrofit the existing packages into this model if your packaging system didn't launch with developer-managed keys from day one (which Cargo didn't) > > There's a system that solves all these problems called The Update Framework (TUF), collaboratively developed by both Tor developers and academics: > > http://theupdateframework.com/ > > The Update Framework allows developers to opt-in to managing their own keys. High profile packages can be signed by developers: specifically, TUF supports "threshold signatures" so k / n developers are needed to countersign a package in order for it to count as released. However, not everyone is forced to manage their own keys: people who don't want to can have their packages signed by the package repository instead. > > TUF secures developer keys by having developers who own "unclaimed" packages request to associate some signing keys with them. A system administrator then periodically (once a week or other tolerable time interval) signs these developer keys with an offline key (or keys, TUF uses threshold signatures everywhere). At this point, these packages move from "unclaimed" to "claimed", and become what TUF calls a "delegated target": the developers, not the packaging system, become the source of truth for that particular package. > > For more information, I suggest you read their paper "Survivable Key Compromise In Software Update Systems": > > http://freehaven.net/~arma/tuf-ccs2010.pdf > > I think a system like TUF can easily be retrofitted to Cargo as it exists today. There are a few changes I might recommend before you try to add TUF, but I think you're off to a good start. > > However, if you did want to use something like TUF, it does figure into the overall AuthZ model of the system. There are a number of outstanding AuthZ issues / suggestions like #48 and #58. If you do want to integrate a system like TUF where developers manage their own keys, it will definitely influence whatever AuthZ model you adopt, because TUF moves things like authorization and integrity partly to the client. > > I worked on adding TUF to RubyGems at one point and liked it, although we never finished. The people behind it worked on adding it to PyPI, and were very helpful with our efforts to add it to RubyGems. There's also a tracking issue for a potential integration with Sigstore, which is currently being explored by RubyGems: > > > Creating this issue to start gathering thoughts on crates sigstore signing. > > …## Current Status > > Cargo performs no signing verification of crates at present. > > Users running the \`cargo install\` command will download unsigned code which will be compiled and executed. > > There has been discussions around using TUF, but progress is arguably very slow, as its been in discussion for over 5 years now \[0\] / \[1\]. > > In thread \[0\] there appears to be a preference for a TUF based CA / PKI: \*\*\_"So, my vote is for a centrally managed PKI, and more specifically for TUF."\_\*\* > > A pull request was made to sign registry index commits \[2\], was never merged and discussion has moved to this issue \[3\]. Discussions there have dried up (last comment was late last year). Two sigstore community folks @trishankatdatadog and @joshuagl comment on a document produced here at \[4\] which supports what we all believe, TUF + TLOGS is a "belt and braces" approach and they compliment each other. I know @SantiagoTorres has looked at this before. > > \[0\] https://github.com/rust-lang/crates.io/issues/75 > \[1\] https://www.reddit.com/r/rust/comments/6qjpzf/could\_the\_security\_of\_cargo\_and\_the\_crates\_system/ > \[2\] https://github.com/rust-lang/rfcs/pull/2474 > \[3\] https://github.com/rust-lang/cargo/issues/4768 > \[4\] https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-logs Note however that the Cargo team is overwhelmed with open PRs as there aren't enough reviewers for those PRs: > **[Changes at the Cargo Team | Inside Rust Blog](https://blog.rust-lang.org/inside-rust/2022/03/31/cargo-team-changes.html)** > > Want to follow along with Rust development? Curious how you might get involved? Take a look! It would probably make sense to explore any of these integrations via a 3rd party tool, prototyping and proving them out in a way which doesn't require direct integration with Cargo or [crates.io](http://crates.io), and exploring a potential direct integration with Cargo as a next step. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [July 3, 2022, 4:31pm UTC](https://internals.rust-lang.org/t/about-release-dead-code-crates/16350/15 "2022-07-03T16:31:34Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.