Requiring 2FA to Publish to Crates.io

Finn · July 21, 2018, 9:13am

Why not simply use the hash value of a crate. After reviewing that crate, the name+version and hash value is added to a whitelist. Such a system could be distributed, many people would reviewing crates independently and one could compute the intersection of whitelists. Or people could link to whitelists they trust, building a web of trust. Furthermore a factor could be stated, indicating how much someone trusts a certain crate or whitelist.

The pros is ultimate security. The cons is complications during development and debugging.

Soni · July 21, 2018, 5:46pm

hmm. a blockchain with a block algorithm that only accepts crates.io-signed blocks and refuses to replace packages/versions would solve the MITM problem I think. without being power-hungry and without 51% attacks. altho it’s still hackable.

bascule · July 21, 2018, 6:08pm

A simpler alternative to a blockchain is a transparency log like Certificate Transparency. Mozilla has done some work on applying this to the problem of binary transparency here:

https://wiki.mozilla.org/Security/Binary_Transparency

nyarly · July 21, 2018, 8:49pm

I found this article unhelpful. While Stufft observes a number of real challenges in the space, at the root there’s a very common philosophy: “if it can’t be perfect, it’s not worth it.” They don’t present a solution, or argue that there isn’t a problem to solve.

Contemporary with this article was the beginning of TUF, which was being developed specifically to address the Python infrastructure - which is a bigger challenge, IMO, than Crates is. Since then, TUF has been adopted as the foundation of Docker Notary. It’s a solid approach that might be able to be applied wholesale.

bascule · July 21, 2018, 9:23pm

Yeah, he didn't know about TUF at the time he wrote it, and later remarked that TUF addresses enough problems that it's actually worth it:

https://twitter.com/dstufft/status/699324070790352897

felix91gr · July 22, 2018, 6:46am

Oh wow. Now that I’ve studied TUF a little bit, I think it’s amazing. Thanks for bringing it up, I’ve learned something really cool ^^

Coming back to the conversation: I think TUF might be a really good option. It assumes there will be compromise of keys, and works to mitigate whatever impact that could have. That’s really awesome.

If anyone wants to check TUF out, I’d recommend this video, which helped me a lot to really get the system.

bascule · July 22, 2018, 1:58pm

In case you missed it, there's an open proposal to add TUF to crates.io here:

github.com/rust-lang/crates.io

Security model / TUF

opened 01:02AM - 24 Nov 14 UTC

tarcieri

C-enhancement ✨ A-infrastructure 📡

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.

I've also been discussing a "minimum viable TUF" here:

github.com/rust-lang/rfcs

New RFC: signing registry index commits

rust-lang:master ← withoutboats:signing-registry-commits

opened 07:52AM - 14 Jun 18 UTC

withoutboats

+358 -0

This RFC proposes signing the commits to the index of a registry, and for cargo …to automatically verify these signatures. It additionally includes a proposed system for performing key rotations. It is intended to be a minimal, intermediate step toward improving the security of cargo registries (including crates.io) without completely replacing the existing index system. Thanks to Henry de Valence, André Arko, Yehuda Katz and Tony Arcieri for providing feedback on this RFC prior to publishing. [Rendered](https://github.com/withoutboats/rfcs/blob/signing-registry-commits/text/0000-signing-registry-commits.md)

Soni · July 22, 2018, 3:17pm

can’t you just MITM that? what stops someone from MITMing that?

bascule · July 22, 2018, 4:08pm

What stops someone from MitMing a CT log? CT logs are designed to be cryptographically verifiable (indeed the main use case is verifying X.509 certificates prior to opening TLS connections).

It carries a digital signature (i.e. a Signed Tree Head, or STH). To verify something is included in the log you need an inclusion proof (i.e. fragment of a Merkle tree) which is ultimately rooted in an STH. If there isn't an inclusion proof for a particular binary, it isn't trusted.

You can read more here:

Soni · July 22, 2018, 6:58pm

okay, so it’s basically equivalent but with single points of failure.

system · March 25, 2019, 8:30am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Security fence for crates tools and infrastructure	50	3117	March 25, 2019
Crates.io is at risk of wormable malware tools and infrastructure	41	3095	September 29, 2023
Vendor lock-in	11	1066	March 25, 2019
Securing cargo publishing credentials tools and infrastructure	27	2334	May 24, 2021
Cargo may leak private tokens when overriding the crates.io index cargo	1	766	April 12, 2019

Requiring 2FA to Publish to Crates.io

Related topics