On 1 January 2015 at 02:54, Paul Moore <p.f.moore@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".


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia