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

[Donald Stufft]

> On Jan 2, 2015, at 1:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 2 January 2015 at 16:13, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> 
>> On Jan 2, 2015, at 12:57 AM, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
>> 
>> To raise the cost of a compromise through distributed signing authority, we have to solve the trust management problem - getting developer keys out to end users in a way that doesn't involve trusting the central PyPI service. That's actually a really difficult problem to solve, which is why we have situations like TLS still relying on the CA system, despite the known problems with the latter.
> 
> 
> I haven’t read the entirety of your email, but I would like to point out that PEP 480 does not attempt to solve this problem without trusting PyPI. Rather it just moves the trust from trusting the server that runs PyPI to trusting the people running PyPI itself. TUF is fundamentally extremely similar to the CA system except there is only one CA which is scoped to a particular repository (e.g. PyPI) and it includes some distribution specific stuff like file size and delegating partial trust.
> 
> That's the part I meant - the signing of developer keys to delegate trust to them without needing to trust the integrity of the online PyPI service.
> 
> Hence the idea of instead keeping PyPI as an entirely online service (without any offline delegation of authority), and suggesting that developers keep their *own* separately signed metadata, which can then be compared against the PyPI published metadata (both by the developers themselves and by third parties). Discrepancies becoming a trigger for further investigation, which may include suspending the PyPI service if the the discrepancy is reported by an individual or organisation that the PyPI administrators trust.

I’m confused what you mean by “without needing to the trust the integrity of the online PyPI service”.

Developer keys get signed by offline keys controlled by I’m guessing either myself or Richard or both. The only time we’re depending on the integrity of the machine that runs PyPI and not on an offline key possessed by someone is during the window of time when a new project has been created (the project itself, not a release of a project) and the next time the delegations get signed by the offline keys.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150102/d2fc67ff/attachment-0001.html>