theupdateframework / pypi.updateframework.com Goto Github PK

Presently, each role is limited to (t, n) = (1, 1) signatures. We need to design and implement a realistic number of keys required to sign for every role. This would probably need to happen in tandem with #1.

We should be smarter about how we generate the metadata.

For example, instead of generating the metadata for all /simple targets, followed by metadata for all /packages targets, we should instead do the following.

For each /simple target, generate its metadata, followed immediately by the metadata for all the packages of that simple target. This way, we can start "streaming" the completed PyPI packages as we generate metadata.

Let's say we delegated from role A to role B when A and B existed on PyPI. Later, PyPI deletes B. The automation then needs to revoke B from A's metadata.

Presently, the metadata are designed to expire in a time long enough for a static data repository. This is convenient for a repository that never changes, but not for PyPI which continuously changes. We need to design and implement proper metadata expiry times for every role.

We should turn on SSL for mirror1.poly.edu.

Presently, the passwords for roles are public knowledge. We need a way to keep passwords unpredictable and secret.

We should close and mark this repo as a read-only archive, no?

Presently, our TUF-secured PyPI mirror is not kept reasonably up-to-date with the official PyPI index. We need to adapt the server automation to allow for the continuous release that this enhancement will require.

We should distribute comprehensive metadata of target delegations with TUF-enabled PyPI installers (e.g. pip).

What do I mean by this? Mustn't a TUF-enabled PyPI installer already come with basic metadata about targets? Yes, but then the first update will then be slow simply because we first have to download metadata about all the target delegations.

We can improve the initial update by distributing at least metadata about long-term target delegations, if not the latest the data about all the short-term target delegations (e.g. new versions of packages).

At the moment, we are studying the worst case of how much metadata would be required if we wanted every /simple target to be signed with its a unique key.

A more efficient method, albeit one which trades off some security, is to use a key to sign up to, say, 1,000 /simple targets and their corresponding /packages targets.

As pypi.python.org changes, so must pypi.updateframework.com, and efficiently so. Initial setup may be expensive, but updates must be much cheaper.