Questions about PEP 458 / 480

PSF PyPI Q4 RFI
1

From the other thread…

2

How does a developer revoke an Ed25519 key or authenticate a new key to PyPI?

Not the only answer, but see “Securely revoking a project key” in Section 6.3 (“Using Diplomat”) of the Diplomat paper, where we discuss PEPs 458/480 in great detail.

What prevents an account from being compromised and having a new developer key uploaded to sign a malicious update?

I’m sure you realize this isn’t a problem you can solve only cryptographically. You’d need social proofs and controls, like publishing to Twitter, Keybase, certificate transparency logs, blockchains, etc.

I’m also still not sure I understand who signs the root.layout .

The developer, using the same “master” project key published to PyPI.

3

After a few hours of reading about TUF, in-toto and Diplomat, I’m having a little trouble understanding where one starts and another begins. However, everything proposed so far has seemed technically reasonable, though it looks like it has more complexity than might preferred.

In section 6.3 it mentions “To use Diplomat to protect a project, a developer must create a public / private key pair and up-load the public key to their community repository”. I can’t find the example of what that repository is supposed to look like. Is this it?

This is why we are advocating that something like EigenTrust as a complement to TUF.

4

After a few hours of reading about TUF, in-toto and Diplomat, I’m having a little trouble understanding where one starts and another begins.

Sorry, I know there’s a lot going on. Diplomat is just an academic codename for TUF. in-toto buys you security between developers and repositories. TUF buys you security between repositories and end-users. You put them both together, you get transparent bootstrapping and rotation of trust, and E2E security between developers and end-users. I hope this makes better sense now.

However, everything proposed so far has seemed technically reasonable, though it looks like it has more complexity than might preferred.

From experience, I can say that the complicated bits are mostly in one-time setup work.

I can’t find the example of what that repository is supposed to look like. Is this it?

Sorry, what do you mean by what the repository is supposed to look like? Do you want to see just the metadata, or also the web services that let you update the metadata as well?

This is why we are advocating that something like EigenTrust as a complement to TUF.

I’ll take a deeper look at EigenTrust. For supply chain security, have you looked at in-toto?

5 
{ "signed" : {
    "_type" : "layout",
    "expires" : "<EXPIRES>",
    "keys" : {
        "<BOBS_KEYID>" : "<BOBS_PUBKEY>",
        "<ALICES_KEYID>": "<ALICES_PUBKEY>"
     },
    "steps" : [
      { "_name": "write-code",
        "threshold": 1,
        "expected_materials": [],
        "expected_products": [
          ["CREATE", "foo.py"]
        ],
        "pubkeys": [
          "<ALICES_KEYID>"
        ],
        "expected_command": "vi"
      },
      { "_name": "package",
        "threshold": 1,
        "expected_materials": [
          ["MATCH", "foo.py", "WITH", "PRODUCTS", "FROM", "write-code"]
        ],
        "expected_products": [
          ["CREATE", "foo.tar.gz"]
        ],
        "pubkeys": [
          "<BOBS_KEYID>"
        ],
        "expected_command": "tar zcvf foo.tar.gz foo.py"
      }
    ],
    "inspect": [
      { "_name": "inspect_tarball",
        "expected_materials": [
          ["MATCH", "foo.tar.gz", "WITH", "PRODUCTS", "FROM", "package"]
        ],
        "expected_products": [
          ["MATCH", "foo.py", "WITH", "PRODUCTS", "FROM", "write-code"]
        ],
        "run": "inspect_tarball.sh foo.tar.gz"
      }
    ]
  },
  "signatures" : [
    { "keyid" : "<ALICES_KEYID>",
      "method" : "ed25519",
      "sig" : "90d2a06c7a6c2a6a93a9f5771eb2e5ce0c93dd580be..."
    }
  ]
}

For the parts of TUF related directly to PEP458 I agree. However, the in-toto approach above seems more complicated than the approach below. I understand how the in-toto approach my be the only way to cover all use cases. It seem to me that if PyPI is doing the builds, you should be able to generate the root.layout from just the information below and the setup.py for 80% of the packages. We wanted to be able to verify a git commit history, but replace or append with Ed25519 public keys as desired.

---
organization:
  name: HXR
  home: https://hxr.io/
  members:
    - link: acct:code@hxr.io
      pgp-fingerprint: CA3275D4E5BAD5F172D680757C98F3C79CCA7823
  alumni:
    - link: acct:dev@hxr.io
      pgp-fingerprint: 962D475D3D2DCBE2D978C0BB7E9CC95FC048EC0C
      active: 2019-09-05T01:11:29-04:00/2019-09-05T01:11:31-04:00

The way I read the diplomat paper was that “community repository” ~= Github repository
So I was expecting something more like https://github.com/LucidOne/myawesum/.tuf.acl than a web service.

The TL;DR idea is a federated trust system for public keys and hashes.

A way for developers to state, “I downloaded this package and checked these signatures and packages”. We are already maintaining lists of GPG public keys and hashes for internal deployments with Ansible, so why not share to help achieve consensus.

6

None of the TUF and in-toto metadata is meant for human consumption, so it really doesn’t matter how complicated it looks, just whether it’s able to cover use cases, even unexpected ones.

7

Thanks to everyone for participating in this discussion! The RFI period has closed, and replies in this category have been disabled.

Based on the feedback, we’ll be updating our scope before opening the Request for Proposals period next week along with a new discussion category.

If you’re interested in participating in the RFP sign up at https://forms.gle/redWdNhwMqzRG1jC8 to be notified when it launches.