Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security model / TUF #75

Open
tarcieri opened this issue Nov 24, 2014 · 75 comments
Open

Security model / TUF #75

tarcieri opened this issue Nov 24, 2014 · 75 comments

Comments

@tarcieri
Copy link
Contributor

@tarcieri tarcieri commented Nov 24, 2014

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.

@vladimir-v-diaz
Copy link

@vladimir-v-diaz vladimir-v-diaz commented Dec 4, 2014

Hi Rust community,

I am one of the developers working on the The Update Framework (TUF). If any Cargo developers would like to discuss the TUF project, we can be reached at theupdateframework@googlegroups.com. We would be happy to answer any questions and start a dialogue on our mailing list, here, or over video/voice chat.

In addition to the documentation provided by Tony Arcieri (@tarcieri), you may find our integration proposal for the Python Package Index (PyPI) interesting. The Surviving a Compromise of PyPI proposal for PyPI provides information on how the framework can be integrated with a community repository, and also includes an overview of the framework. The proposal (broken into two parts) can be found here:

PEP 458: http://legacy.python.org/dev/peps/pep-0458/
PEP 480: http://legacy.python.org/dev/peps/pep-0480/

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Dec 5, 2014

Thanks for the offer @vladimir-v-diaz! I'll be sure to reach out to you if we need help :)

For now I'm going to be focusing a large amount of effort towards Rust's standard library, so this may be postponed for awhile, but I'd love to see something like this implemented!

@l0kod
Copy link

@l0kod l0kod commented Feb 8, 2015

Some proposals in rust-lang/cargo#1281.

Is there any news for this issue? It would be good to have a trusted crates.io-index for Rust 1.0.

@richo
Copy link

@richo richo commented Feb 9, 2015

I've had this tab open for months. If someone else spearheads I can work on
it but no time to champion.

On Sunday, February 8, 2015, Mickaël Salaün notifications@github.com
wrote:

Some proposals in rust-lang/cargo#1281
rust-lang/cargo#1281.

Is there any update for this issue? It would be good to have a trusted
crates.io-index for Rust 1.0.


Reply to this email directly or view it on GitHub
#75 (comment).

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Feb 9, 2015

@l0kod I have done no work on this but would be interested in collaborating. I helped write a partial implementation of TUF for RubyGems, but we never managed to carry it over the finish line.

@kamalmarhubi
Copy link

@kamalmarhubi kamalmarhubi commented May 2, 2015

Is this being worked on? I've recently been interested in verifiable provenance of software artefacts, and would be much more comfortable if Rust and Crates.io had a better story here. I'd be willing to help with drafting an RFC drawing on PEP 458 and PEP 480 mentioned above. This is not an area of expertise for me, so I'll need to consult others, but it sounds like some with more experience are interested in helping.

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented May 3, 2015

@kamalmarhubi to my knowledge this is not actively being worked on unfortunately

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented May 3, 2015

@kamalmarhubi if you're interested in working on this, the creators of TUF are at least pretty responsive on their mailing list:

https://groups.google.com/forum/#!forum/theupdateframework

@vladimir-v-diaz
Copy link

@vladimir-v-diaz vladimir-v-diaz commented May 3, 2015

@kamalmarhubi We'd be happy to collaborate with you on an RFC draft for the Rust community. Did we meet at PyCon 2015?

As @tarcieri suggested, our mailing list would be a good place to start a discussion. @JustinCappos @Dachshund and I are available to work with you on this draft.

Note: The Python proposal was recently updated and is available here

@kamalmarhubi
Copy link

@kamalmarhubi kamalmarhubi commented May 4, 2015

@tarcieri thanks for the link!

@vladimir-v-diaz I was definitely at PyCon, but I'm terrible at names and faces. To help narrow things down: I was session chair for a couple of sessions, and spent a lot of time in the green room. I am sad I missed the poster on this topic though!

What's the best venue to get in touch about this topic? This bug? TUF mailing list? Somewhere else?

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented May 4, 2015

@kamalmarhubi I'd recommend the TUF mailing list as a starting place. This is something I'm interested in working on, but I'd also like to help finish up applying TUF to RubyGems before I'd have time to start working on a TUF implementation for Rust.

I'm familiar with both TUF and Rust though, as well as Cargo, and just generally am way too overinterested in cryptography and infosec so at the very least I can help consult / review code if you'd like to do the implementation work! 😉

@kamalmarhubi
Copy link

@kamalmarhubi kamalmarhubi commented May 5, 2015

@tarcieri sounds good. I'll send an intro email there soon enough. :-)

@genodeftest
Copy link

@genodeftest genodeftest commented Dec 12, 2015

Any progress on this?
Two days ago, Rust 1.5 was published, providing a cargo install command. With this command unsigned code will be downloaded, compiled and installed. If the git repo isn't provided on an encrypted connection, it will even download, compile and install unsigned code from an unencrypted (completely insecure) connection.
Are we back to the 90ies, when all downloads were unsigned and insecure?

I suggest some immediate changes:

  1. warn for every single piece of software that it is unsigned (and thus horribly insecure to run)
  2. don't allow to git checkout over unencrypted connections at all. Except when code is signed (see 4.)
  3. suggest (later version: require) crates releases to be signed by the crate author
  4. use Web of Trust or PKCS to verify signatures; fall back to TOFU (trust on first use) after warning and confirmation by the user.

As long as these (or equivalent) measures aren't taken, every developer and user of rust-based software out there is at high risk.

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Dec 12, 2015

@genodeftest perhaps we need to back up and look at the actual threats:

With this command unsigned code will be downloaded, compiled and installed. If the git repo isn't provided on an encrypted connection, it will even download, compile and install unsigned code from an unencrypted (completely insecure) connection.

So your problem is that cargo install --git http://... allows people to install crates over plaintext HTTP (thereby enabling a MitM to swap out the code)? This issue is about data-at-rest authentication of published crates, which isn't really possible with unpublished crates fetched via git. I would agree that if someone does cargo install over http:// printing a warning might be in order, or even disallowing this behavior at all. I think that's the topic for a separate issue, though.

All that said, as far as I know, beyond that cargo publish and cargo install are both delivered over https://. So the threat ceases to be a MitM, but an attacker who can compromise crates.io. Such compromises do happen frequently: the main thing that spurred my interest in TUF was the RubyGems compromise, and similar attacks have happened to many major languages' package repositories at some point.

But I think you're slightly overstating the severity of the issue, and making a bunch of recommendations that are half-measures that wouldn't significantly improve the security of the system but would certainly harm the cargo user experience.

To go through these:

  1. Web-of-Trust (the OpenPGP model): developers create signing keys, and perhaps meet up at conferences and have a keysigning party. Everyone comes home with the keys of a few developers they trust, and can use that to bootstrap the trust model of the system This is the ideal of the early cypherpunk days, unfortunately it has this painful problem of wasting everyone's time without ever really working as effectively as people hoped it would. As a small anecdote, most of the people I trust in the security community tend to view WoT and keysigning parties rather skeptically. I think there may be a deep-rooted flaw in the approach: I'm not really sure which friends or fellow developers I actually trust to delegate trust to, and it only takes one bad trust delegation to poison the whole web, unless for every bad delegation someone else exists to identify it. When this happens though, as a user I'm just told the WoT is conflicting: what do I do now? It's not clear what this means: is something malicious happening? Did someone make a mistake? What are my action items as a user? You can contact the people in question, but will they even remember why they signed a particular key? The WoT makes every member into a certificate authority, but it turns out being a certificate authority is hard and involves, among other things, due diligence in checking identities and meticulous record-keeping.

  2. Public Key Infrastructure (the X.509 model): (you said PKCS, but this is what I assume you meant): under this model, a central certificate authority would sign developer keys, hopefully including some name constraints around what packages they're allowed to sign. RubyGems implemented PKI-based gem signing, but punted on the hard problem: who runs the CA? Further difficult problems: what do we do with all the packages that aren't signed?

TUF implements what is effectively a non-X.509 PKI specifically designed for the purposes of authorizing developers to sign certain packages in the system, and without the added undue complexity needed to handle non-codesigning use cases.

In a TUF PKI, someone like Mozilla would run a developer CA. Developers would provide some form of authentication along with a public key to be signed. The operators of the CA can then sign the developer keys offline (using e.g. an HSM, Yubikey, etc) and publish the signed keys via crates.io.

  1. Trust on First Use (TOFU): prompt the user to verify each and every public key fingerprint, or blindly accept them for the user, and store these fingerprints away for eternity hoping they don't change. When they do change, pop up a scary warning message, and hope that incentivizes the user to do enough investigation to find out why the key changed. TOFU ultimately ends up conditioning users to ignore these messages, because key rotation happens quite frequently and the ratio of developers to crates will likely continue to be 1:1.

I find that #1 is impractical and doesn't typically end up working out the way people would like it to. #3 doesn't add much effective security, and has a poor user experience, constantly prompting the user whenever there's any breakage in key continuity, and providing no additional context as to what happened.

So, my vote is for a centrally managed PKI, and more specifically for TUF. As one last note:

TUF is a hybrid system which allows "unclaimed" packages to be centrally signed by the packaging system, and "claimed" packages to be signed by one or more developers. This means under TUF, all packages are signed in some form. Even packages published before the addition of the signing system can be retroactively signed.

I think unless you find some way to solve this problem, a package signing system has little value.

@genodeftest I sense some urgency on your part, but this is a problem I'd really rather see done right as opposed to rushed out the door just to have "something". Unless it solves the problem of signing every crate, and doing so in a way that does not require every developer to get a cryptographic key to publish crates (impossible already as crates have already been published without associated cryptographic keys), and it does not require the user make lots of decisions about which keys to trust or how to bootstrap the system trust model, I don't think it's helpful.

So those are my two requirements for a good package signing system:

  1. Doesn't require substantial changes to the existing crates.io workflows: should largely be transparent
  2. Signs every single package in the system, even retroactively, in some form or another
@genodeftest
Copy link

@genodeftest genodeftest commented Dec 13, 2015

  1. about cargo install --git http://something
    No, you don't need to specify the --git option. Any git repo in crates.io index is a potential threat if its git URL is not encrypted. The attacker may not need to break the index, he can put his stuff MitM in a git repo loaded by cargo install via http. Did I get something wrong here?

  2. and 2): Both OpenPGP and X.509 protect from a random attacker with limited capacities. I know that both don't protect from NSA&co due to their centralism (Who runs the CA?) or their diversity (OpenPGP). But they'd help against basic attacks. TUF looks like a good solution to that.

I forgot one point: even if a git repo is fetched via HTTPS, how can we be sure that nobody put other commits into a git repo? Seems like TUF has some solution to that too. But it isn't implemented yet.

@genodeftest I sense some urgency on your part, but this is a problem I'd really rather see done right as opposed to rushed out the door just to have "something". Unless it solves the problem of signing every crate, and doing so in a way that does not require every developer to get a cryptographic key to publish crates (impossible already as crates have already been published without associated cryptographic keys), and it does not require the user make lots of decisions about which keys to trust or how to bootstrap the system trust model, I don't think it's helpful.

You could sign those git commits afterwards. That's how many people do releases: Put a git tag up, create an archive and sign the archive. If the crates index could do the signing, it must make sure that only the intended author can submit this archive/checksum/whatever.

Sorry, I was kinda overreacting, possibly because I didn't get the features yet implemented. I think this issue is urgent though.

So those are my two requirements for a good package signing system:

  1. Doesn't require substantial changes to the existing crates.io workflows: should largely be transparent

+1

  1. Signs every single package in the system, even retroactively, in some form or another

But do some authentication against the author to do that.

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Dec 13, 2015

Any git repo in crates.io index is a potential threat if its git URL is not encrypted

I think this can be mitigated by blocking or warning on plaintext git repos. Perhaps they can be blocked by default, with an option to allow crazy people to use plaintext git. Anyway, I think that should be handled as a separate issue than this one.

I forgot one point: even if a git repo is fetched via HTTPS, how can we be sure that nobody put other commits into a git repo? Seems like TUF has some solution to that too. But it isn't implemented yet.

I think in general handling signatures with git repos will be difficult. A commit hash for a dependency can be included in the signed metadata for a given crate, but that only helps the case where a signed crate references another crate over git.

For the case of cargo install --git though, I think things get a lot trickier. Whose key do you use to authenticate that URL?

If "TUF for Rust" used GPG to implement signatures and had a keyring of anyone who's ever published a crate to crates.io, you could validate signed commits or tags against that GPG keyring, but without knowing specifically which key to trust the best thing you can do is tell the user you found some key in the keyring, and then ask the user to make a decision about whether it's the correct one. I think these systems which rely on user choice for security don't really add a lot of value.

But do some authentication against the author to do that.

Exactly how much identity verification will happen is really up to whoever runs the developer CA (just gonna say Mozilla from here on out). I expect they will want the CA to be completely automated.

From what I can tell, OAuth2 with GitHub is the only source of authentication / authorization that crates.io presently uses. It'd be nice if authorizing a given public key for a particular crates.io account had some degree of authentication beyond that. crates.io seems to pull in email addresses from GitHub after you first link an account, so it could at least be a combination of being authorized with OAuth2 and clicking a particular link in your email.

I expect Mozilla lacks the time and resources to do any sort of non-automated identity verification beyond that.

@retep998
Copy link
Member

@retep998 retep998 commented Dec 13, 2015

Crates on crates.io referencing other crates in git repos shouldn't be a problem anyway as crates.io requires that all dependencies of a crate must be on crates.io as well.

If there was a way for me to assign a key to my crates.io account and sign all my crates with my key when publishing them, I'd definitely be in favor of that.

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Dec 13, 2015

@retep998 I haven't actually tried this, but can you publish a crate that has a git dependency?

@retep998
Copy link
Member

@retep998 retep998 commented Dec 13, 2015

@tarcieri Nope, it will reject it.

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Dec 13, 2015

@retep998 if that's the case, it simplifies the security model to static files only, which is a great property

@ticki
Copy link

@ticki ticki commented Jan 17, 2016

Another (very conservative) approach would be to deprecate version wildcards. This would also improve stability.

@retep998
Copy link
Member

@retep998 retep998 commented Jan 17, 2016

@ticki We're already deprecating version wildcards on crates.io!

@heartsucker
Copy link

@heartsucker heartsucker commented Aug 2, 2017

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
Copy link
Contributor Author

@tarcieri tarcieri commented Aug 29, 2018

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

withoutboats/rfcs#7

@Yoric
Copy link

@Yoric Yoric commented Dec 12, 2018

@kornelski
Copy link
Contributor

@kornelski kornelski commented Jan 9, 2019

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
Copy link

@JustinCappos JustinCappos commented Jan 10, 2019

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Jan 10, 2019

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
Copy link

@jchesterpivotal jchesterpivotal commented Jan 10, 2019

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.

bors added a commit that referenced this issue Dec 18, 2019
….6.0, r=locks

Bump ember-percy from 1.4.0 to 1.6.0

Bumps [ember-percy](https://github.com/percy/ember-percy) from 1.4.0 to 1.6.0.
<details>
<summary>Release notes</summary>

*Sourced from [ember-percy's releases](https://github.com/percy/ember-percy/releases).*

> ## v1.6.0
> ## What changed?
>
> This version of ember-percy includes more from input serialization when taking the DOM snapshot. You should now see all form inputs properly capture their state ([#146](https://github-redirect.dependabot.com/percy/ember-percy/issues/146))
>
> ## v1.5.0
> Bower was removed - [#73](https://github-redirect.dependabot.com/percy/ember-percy/issues/73)     🎉 🌮 🎉 🗡
> Node 4 was removed from testing - [#75](https://github-redirect.dependabot.com/percy/ember-percy/issues/75) & [#74](https://github-redirect.dependabot.com/percy/ember-percy/issues/74)
> PERCY_PROJECT environment variable is no longer required - [#72](https://github-redirect.dependabot.com/percy/ember-percy/issues/72)  🚀
> Some defensive programming was added - [#71](https://github-redirect.dependabot.com/percy/ember-percy/issues/71) (thanks [@&#8203;Gaurav0](https://github.com/Gaurav0)!) 🛡
>
> ## v1.4.4
> **Important bugfix, please upgrade:**
> - Fix duplicate asset clobbering resource paths. ([#70](https://github-redirect.dependabot.com/percy/ember-percy/issues/70))
>
> ## v1.4.3
> Do not release yarn.lock to npm. Thanks [@&#8203;Turbo87](https://github.com/Turbo87)!
>
> ## v1.4.2
> Fix jQuery version conflict bug. ([#65](https://github-redirect.dependabot.com/percy/ember-percy/issues/65))
>
> ## v1.4.1
> 🐛 Reintroduce support for older ember apps that don't know about `@ember/test` yet.
</details>
<details>
<summary>Commits</summary>

- [`dd7288c`](percy/percy-ember@dd7288c) v1.6.0
- [`a31d5b4`](percy/percy-ember@a31d5b4) feat: Add more form element serialization  ([#146](https://github-redirect.dependabot.com/percy/ember-percy/issues/146))
- [`e387464`](percy/percy-ember@e387464) build(deps): Bump handlebars from 4.0.11 to 4.2.0 ([#145](https://github-redirect.dependabot.com/percy/ember-percy/issues/145))
- [`868783a`](percy/percy-ember@868783a) build(deps): Bump underscore.string from 3.3.4 to 3.3.5 ([#144](https://github-redirect.dependabot.com/percy/ember-percy/issues/144))
- [`8442380`](percy/percy-ember@8442380) build(deps-dev): Bump ember-cli-htmlbars-inline-precompile ([#140](https://github-redirect.dependabot.com/percy/ember-percy/issues/140))
- [`9f503a7`](percy/percy-ember@9f503a7) build(deps-dev): Bump eslint-plugin-node from 9.1.0 to 9.2.0 ([#143](https://github-redirect.dependabot.com/percy/ember-percy/issues/143))
- [`d0786ac`](percy/percy-ember@d0786ac) build(deps): Bump percy-client from 3.0.12 to 3.0.13 ([#142](https://github-redirect.dependabot.com/percy/ember-percy/issues/142))
- [`29877a5`](percy/percy-ember@29877a5) build(deps): Bump ember-cli-babel from 7.10.0 to 7.11.0 ([#141](https://github-redirect.dependabot.com/percy/ember-percy/issues/141))
- [`0109d54`](percy/percy-ember@0109d54) build(deps-dev): Bump ember-load-initializers from 2.0.0 to 2.1.0 ([#139](https://github-redirect.dependabot.com/percy/ember-percy/issues/139))
- [`e8c6f35`](percy/percy-ember@e8c6f35) build(deps): [Security] Bump mixin-deep from 1.3.1 to 1.3.2 ([#138](https://github-redirect.dependabot.com/percy/ember-percy/issues/138))
- Additional commits viewable in [compare view](percy/percy-ember@v1.4.0...v1.6.0)
</details>
<details>
<summary>Maintainer changes</summary>

This version was pushed to npm by [percy-admin](https://www.npmjs.com/~percy-admin), a new releaser for ember-percy since your current version.
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=ember-percy&package-manager=npm_and_yarn&previous-version=1.4.0&new-version=1.6.0)](https://dependabot.com/compatibility-score.html?dependency-name=ember-percy&package-manager=npm_and_yarn&previous-version=1.4.0&new-version=1.6.0)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

**Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com).

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

</details>
@nealmcb
Copy link

@nealmcb nealmcb commented Sep 9, 2020

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:

rust-lang/rfcs#2474 (comment)
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.

Where does that leave this issue?

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Sep 9, 2020

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
Copy link
Contributor

@withoutboats withoutboats commented Sep 9, 2020

Why does the OpenPGP key fingerprint algorithm matter?

@tarcieri
Copy link
Contributor Author

@tarcieri tarcieri commented Sep 9, 2020

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
Copy link
Contributor

@withoutboats withoutboats commented Sep 9, 2020

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
Copy link

@kpcyrd kpcyrd commented Sep 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet