[Distutils] Surviving a Compromise of PyPI - PEP 458 and 480

[Nick Coghlan]

On 1 January 2015 at 02:54, Paul Moore <p.f.moore at gmail.com> wrote:

> I appreciate that the target audience for these PEPs is really PyPI
> admins, at the moment, so maybe it's not the right time to look at
> them from a project author perspective - if so, then feel free to
> ignore these points for now :-)
>

I think capturing the UX consequences is important, especially as that's
actually the key driver behind the split into two PEPs. In theory, the UX
consequences for PyPI hosted projects under PEP 458 should be close to nil
- pip should just silently update to using the additional content
validation mechanism behind the scenes, and thus become capable of
detecting additional forms of illicit tampering that can't be detected
through the existing use of transport layer security.

Projects using external hosting *will* see a UX change under PEP 458, and
that's something that will need to be figured out before the PEP can be
accepted.

PEP 480 is far more challenging from a UX perspective, as it brings in the
notion of developer managed keys and the associated signed uploads. Key
management *is* a pain, especially in distributed developer communities.
Trust management in particular is *not* an easy problem to solve - hence
why we still rely on the CA system for TLS (despite its many known attack
vectors), and why we see the complicated situation around SecureBoot, where
community Linux distributions are generally bootstrapped through a shim
signed through Microsoft's developer program, since that allows them to
"just work" on hardware that only has Microsoft's chain of trust checking
keys pre-installed.

PEP 458 is almost certainly a solid enhancement to PyPI's overall security
(assuming we can come up with an acceptable answer for external hosting).
It's significantly less clear that PEP 480 is the right answer for
delegating more signing authority to developer groups - for example, it may
be better to come up with a federated *hosting* model, where external
hosting is the answer if developers choose to use their own signing keys
rather than PyPI's automated online keys. Things like the Rackspace
developer program, or the emerging next generation of Docker-based
Platform-as-a-Service offerings, make it easier to recommend such federated
hosting models.

As a result, my perspective is that it's the UX design concept that will
make or break PEP 480 - the security model of TUF looks great to me, what
gives me pause is concern over the usability and maintainability of signed
uploads for "developers in a hurry".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150101/4566ca20/attachment.html>