Security model / TUF

[tarcieri]

The fun thing about packaging systems with central package directories is the central 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.

[vks]

Is there any progress on this?

As far as I know, no one started working on this. (I have a very early port of the TUF reference implementation to Rust somewhere, but I'm currently not working on it actively.)

[zmanian]

Any thoughts on how to add signing the build processes in rust-lang/rust/issues/38531

[goldenMetteyya]

Is this being worked on?

[tarcieri]

Yes, I believe @Manishearth is going to start working on it

[Manishearth]

(Not 100% sure if I will, but yes, working on getting through the spec and finding other folks wanting to collaborate)

[heartsucker]

Anyone who is interested, my company is implementing this in Rust at the moment, and I'm pulling the bits I can out into a standalone lib. If anyone wants to contribute, I'd love the help.

https://github.com/heartsucker/rust-tuf

Also, oh hey @JustinCappos. No surprise seeing you here.

[kamalmarhubi]

@heartsucker this is fantastic! As @JustinCappos and others here know, I wanted to work on this but have been failing at it for about two years now. I actually ran cargo new tuf a few days ago and started laying down the metadata types, but you're much further along. I'll be happy to contribute!

[Manishearth]

I'm really busy this month so I'm probably not going to be able to help out too much. Still, willing to do some reviews and stuff.

[JustinCappos]

Good to see you here as well. We're looking forward to help out!

Just let us know if you have any questions or issues.

On Tue, Apr 11, 2017 at 2:18 PM, heartsucker notifications@github.com wrote:

Anyone who is interested, my company is implementing this in Rust at the moment, and I'm pulling the bits I can out into a standalone lib. If anyone wants to contribute, I'd love the help.

https://github.com/heartsucker/rust-tuf

Also, oh hey @JustinCappos https://github.com/JustinCappos. No surprise seeing you here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-lang/crates.io/issues/75#issuecomment-293354225, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD9k75tdzaWcaEgnK07idez4-2xUZks5ru8QMgaJpZM4C_rBb .

[est31]

There is also binary transparency, which is pretty cool... I think crates.io should adopt it as well as TUF.

According to a conversation on IRC with @ckerschb the client part in Firefox will be implemented in C++ and JS, but maybe the server part (python) can be shared.

[demurgos]

There was a recent HN discussion about a malicious package on npm using typo-squatting. Would the security model proposed in this issue help to mitigate this sort of attack against crates.io?

[heartsucker]

No. TUF would not be able to help with that. TUF only says "package P was signed by key K, and K was authorized to sign for P." It does not thing against social engineering like that or even against blatantly malicious packages.

• TUF couldn't stop the maintainers of hyper from doing Bad Things and then pwning everyone's machines once some maintainer is given a key to hyper
• TUF doesn't stop someone from registering hyyper and then uploading malicious content

In the way TUF would most likely be deployed to crates.io, there would need to be a manual key revocation and package removal of an evil crate. However, TUF could prevent the case of a single rouge maintainer from pushing a package by requiring a threshold of signatures from some N maintainers, but this wouldn't be the default.

TUF protects against repository compromise, not intentionally malicious packages.

[tarcieri]

I created a PR to @withoutboats's signing registry index commits PR which uses TUF roles and formats:

https://github.com/withoutboats/rfcs/pull/7

[Yoric]

Probably related: I just posted a fairly simple idea to mitigate risks from malicious crates.

[kornelski]

For anyone interested in crate security, there's cargo-crev project working on verifying crate security, and creating a web of trust for crate authors.

cargo-crev protects against crates-io compromise too, because crev reviews are cryptographically tied to digests of published tarballs, and will catch any modified tarballs.

[JustinCappos]

I've taken a look and the web-of-code-review aspect is quite neat. I'm slightly skeptical about how this scales (due to lessons from Debian, etc. trying somewhat similar things), but I like how it is more informational and on the code review side. That different flavor may make this work in ways that others have failed.

Do you have interest in adding more resilience to an attacker manipulating proofs or messing with CrevIDs? It would be good to have some sort of protection from old proofs being replayed, key revocation in case someone compromises an account, etc.

[tarcieri]

I think an incentivized code review system makes a great deal of sense and would really like to see some successes in that area, and crev looks quite promising, however I think it's somewhat orthogonal to the issues I originally raised in this thread, which are generally "Is the code authentic code created by the purported authors" versus "Is the code good/safe/secure?"

[jchesterpivotal]

however I think it's somewhat orthogonal to the issues I originally raised in this thread, which are generally "Is the code authentic code created by the purported authors" versus "Is the code good/safe/secure?"

Agreed. TUF defends against a different threat model: can an attacker replace or modify packages? Can the attacker mislead you into rolling back your packages, or into not upgrading at all? Can an attacker force you to install inconsistent combinations of packages?

Crev addresses different questions: do I trust the author of the package? Do I trust a particular version of the package?

Of the two I consider TUF's problems to be more pressing. Being able to flush out a bad package version quickly and safely will be required in order to take full advantage of trustworthiness assertions about particular package versions.

[nealmcb]

It looks like there has been significant progress on the use of TUF in general for Rust, with Amazon apparently using it for Bottlerocket: a special-purpose container operating system based on Linux and Rust.

Bottlerocket relies on tough: a new rust implementation of TUF, and I note from above that there is at least one existing beta tuf package.

Bottlerocket's update infrastructure and updog client is documented at bottlerocket/sources/updater.

I also note there is a related postponed RFC: signing registry index commits, about which the Cargo team said:

https://github.com/rust-lang/rfcs/pull/2474#issuecomment-546966957 Cargo team discussed this RFC last week during triage and unfortunately we concluded that we don't have bandwidth at this time to work through this RFC and review it at this time. As a result I'm going to propose that we close this as postponed. We're still very interested in the motivation behind this RFC but at this time we're not quite equipped to handle it.

Finally, note that Python is now moving forward on PEP 458 -- Secure PyPI downloads with signed repository metadata which was "Accepted" in February 2020 and has funding and ongoing development.

• Roadmap update for TUF support · Issue #5247 · pypa/warehouse

Where does that leave this issue?

[tarcieri]

I'm still happy to help work on this issue, be it advising, drafting an RFC, or trying to build a prototype.

There are indeed (at least) two implementations of TUF in Rust now as you mentioned: tough and tuf. I think an interesting thing to do perhaps before even trying to write an RFC is to try to prototype a tool out-of-tree from Cargo which leverages one of those crates and implements some of the functionality, and then use that as motivation/experience report for writing an RFC.

In the original RFC I worked on the goal was to use OpenPGP signatures in-band with Git, however in the intervening time SHA-1 has gone from theoretically broken to practical attacks, and to my knowledge there has been no work to update the OpenPGP key fingerprint algorithm to use a newer algorithm. Given that, I think it would make more sense to use something closer to TUF's current signature formats (i.e. Canonical JSON or ASN.1).

[withoutboats]

Why does the OpenPGP key fingerprint algorithm matter?

[tarcieri]

IIRC the SHA-1 key fingerprints are used in OpenPGP signature subpackets to identify the key which created a signature.

Granted there are various workarounds to avoid an attacker being able to provide a key with a colliding fingerprint.

[withoutboats]

IIRC the SHA-1 key fingerprints are used in OpenPGP signature subpackets to identify the key which created a signature.

You're right. However, this can never lead to a signature signed by a different key being found valid, because such a signature would not validate against the trusted key.

An attacker has always been able to generate an OpenPGP signature with any key fingerprint they want, even without having an actual key that has the same fingerprint. No one's ever proposed a design that would use fingerprints to validate that a key is trusted.

The main advantage of using PGP is still that the host for our registry index (GitHub) supports and understands PGP keys.

[kpcyrd]

I'd argue that it's true that in a curated-keyring-model you wouldn't care about the places in which sha1 is hardcoded into the rfc4880 spec, but that's only because you would barely use any of the OpenPGP features, while still exposing yourself to all its complexity. Personally I'd prefer something that has less historical baggage attached to it.

Github only understands PGP as-in signed git commits, which would effectively boil down to signed sha1 merkle-trees, making sha1 collisions a problem again.

[jchesterpivotal]

Potentially-useful trivia: Git can sign commits with X509 certificates.

Github themselves maintain a tool for this purpose.

[xloem]

if commits to the index were signed, it would add a lot of integrity to this situation until a full solution is implemented

[tarcieri]

@xloem FWIW, that was the goal of this work, which would initially implement index signing only, but leave the door open to a full TUF integration later:

https://github.com/withoutboats/rfcs/pull/7

[xloem]

Even basic git commit or tag signatures would really help here. A stop-gap measure is needed.

[tarcieri]

If you take a look at that proposal, it's using git commit signatures.

However, the problem with git commit signatures is how you manage the keys used to verify them. That is the other problem addressed by that proposal.

[xloem]

It's true the proposal is better. I infer there are things blocking it. Even imperfectly managed signature keys used for basic no-frills git commit or tag signatures would significantly reduce the attack surface here, and be familiar for users to verify. It's been seven years, what's possible to push through? What's simple and small?

[tarcieri]

I think the biggest thing holding back these proposals is a lack of people willing to do the work.

That said, there is some interest from the sigstore community in doing the work:

https://github.com/sigstore/community/issues/25

What's simple and small?

IMO, these proposals are as simple and small as they can be to provide a meaningful solution to the problem.

[kaidokert]

Sigstore developers presented a "The state of Signing" across various language and packaging ecosystems. This work is tracked by OpenSSF "Digital Identity" WG. Perhaps helpful, as it covers various trust models and formats.

[nealmcb]

Sounds great- thanks! But re the google doc The state of Signing, I get a permission error: "You need access".

[kaidokert]

Sorry - the link was in WG meeting notes doc (under 2021-03-17 ), i believe g/ossf-wg-developer-identity membership is needed. I wrongly assumed it's fully public

[tarcieri]

Can confirm I was able to access the State of Signing slides after joining g/ossf-wg-developer-identity

[L0g4n]

Sorry, I did not want to look at all these comments posted in this thread, but: Whats the current state of this issue? Is integrating TUF into crates.io actively being worked on? If so, I might be interested to help working on that.

[Kixunil]

@L0g4n my understanding is that there are simply too many possible designs, trade-offs etc so it's difficult to agree on something and the discussion stalled. Lately, I've been seriously considering writing something simple and independent, so that we can get at least something and iterate from that.

[realtimetodie]

https://github.com/theupdateframework/rust-tuf

[tarcieri]

FYI, here's an IRLO post on using Sigstore to sign crates: https://internals.rust-lang.org/t/pre-rfc-using-sigstore-for-signing-and-verifying-crates/18115

[JustinCappos]

Okay, thanks. We will take a look!

FYI: we're working with the SigStore folks with the aim of supporting Fulcio signatures natively in TUF. The intent from both sides is that integrating TUF and then using Fulcio signatures will become the preferred way for a registry to integrate SigStore.

On Tue, Jan 10, 2023 at 9:01 AM Tony Arcieri @.***> wrote:

FYI, here's an IRLO post on using Sigstore to sign crates: https://internals.rust-lang.org/t/pre-rfc-using-sigstore-for-signing-and-verifying-crates/18115

— Reply to this email directly, view it on GitHub https://github.com/rust-lang/crates.io/issues/75#issuecomment-1377328473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODYC7KZWOIVBZDTP6TLWRVTRXANCNFSM4AX6WBNQ . You are receiving this because you were mentioned.Message ID: @.***>

[tarcieri]

There's now an RFC for signing crates with Sigstore which also mentions TUF: https://github.com/rust-lang/rfcs/pull/3403