[Distutils] PEP draft on PyPI/pip package signing

Donald Stufft donald at stufft.io
Mon Jul 28 22:26:41 CEST 2014


On July 28, 2014 at 1:42:54 PM, Giovanni Bajo (rasky at develer.com) wrote:
>  
> I thus solicit a second round of review of my proposal; if you want me to upload to Google  
> Docs for easier of commenting, I can do that as well. I would love to get the PEP to its final  
> form and then ask for a pronouncement.
> 

In my eyes your proposal is actually three proposals:

* Use GPG to have authors sign packages and publish a trust file to use in
  verifying those signatures.
* Implement 2Fa authentication.
* Implement better notification when security sensitive events occur.

I'm going to split up my feedback based on those three ideas as well as a
general overall feedback.

To be clear, I'm also strongly -1 on the package signing portions of this
PEP and the other portions I'm strongly +1 but they don't require a PEP.


General
-------

Overall the main benefit that would be achieved in this proposal comes from
the 2FA and increased notification/auditability. The package signing exists
mostly as a attractive nuisance which doesn't really win us much for the
increased complexity.

It's true that the TUF PEP, and TUF in general is not particularly approachable
if you're not familiar with it already and especially so if you're not familiar
with implementing secure systems. It is also true that it comes with a fair bit
of complexity, however that complexity mostly exists for good reason.
Establishing trust securely is a complex topic, especially when you're trying
to do it in an open system where anyone can join at anytime and should be able
to be immediately trusted.

For the record the TUF PEP is mostly stalled on me. I'm one of the few people
who are both qualified to review it, who care enough to review it, and who
have the time to review it.


Use GPG for Package Signatures
------------------------------

I have to say, I'm not entirely thrilled by this part of the proposal. I do not
think it gives us much above what we currently have in terms of security and
I think it will muddy the waters and potentially prevent implementing a more
comprehensive solution in the future.

All of the trust in this proposal flows from a simple trust file. Generating
and fetching this file is the weak link in this proposal. Generating this file
relies on PyPI not being compromised and also having a proper state of the
world. The ways in which this falls down are:

* Anyone able to defeat our TLS and is in a position to MITM a regular user
  can simply supply their own trust file.
* Anyone able to defeat our TLS and is in a position to MITM a package author
  can simply register their own GPG key.
* Anyone who has compromised an authors PyPI account can simply register their
  own GPG key.
* Fastly (which is effictively a persistent MITM) could simply modify traffic
  to register their own GPG key.
* Anyone who has compromised PyPI can simply generate their own trust file
  with their own keys.

Now it is true that if we sign the trust file with a key that is stored on
PyPI, then the first one of those cases is no longer possible. However the
remaining three are still there. This means we are still effectively relying
on the security of TLS and thus we've not really gained anything except
additional complexity.

An additional problem is that as an append only file, this file will end up
growing unbounded forever. It's not particularly hard to imagine that this can
cause few problems, especially for new users, who will experience that they
need to download a multi-gig file before they can download anything. It's also
trivial to DoS this by simply generating a ton of things that could cause this
events which need to get written to this file causing it to quickly balloon to
massive proportions, and because the end clients must treat this file as append
only there is zero remediation available to undo the damage caused by this kind
of DoS.


Implement 2FA/Better Authentication
-----------------------------------

Absolutely, we don't need a PEP to do this, we just need to do it. It's on my
personal TODO list but other things have had higher priority thus far.


Implement Better Notifications
------------------------------

Again this is absolutely yes and are also things we don't need a PEP to do and
also on my personal TODO list.

--  
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


More information about the Distutils-SIG mailing list