On 29 Jul 2014 10:01, "Giovanni Bajo" <ra...@develer.com> wrote: > > Il giorno 29/lug/2014, alle ore 01:36, Nick Coghlan <ncogh...@gmail.com> ha scritto: >> >> On 29 Jul 2014 03:43, "Giovanni Bajo" <ra...@develer.com> wrote: >> > >> > Hello, >> > >> > on March 2013, on the now-closed catalog-sig mailing-list, I submitted a proposal for fixing several security problems in PyPI, pip and distutils[1]. Some of my proposals were obvious things like downloading packages through SSL, which was already in progress of being designed and implemented. Others, like GPG package signing, were discussed for several days/weeks, but ended up in discussion paralysis because of the upcoming TUF framework. >> >> It stalled because end-to-end signing is a hard security problem and "just add GPG!" isn't an answer. > > I don’t find it very fair that you collapse a 700-line document to “just add GPG”. And even in March, I wrote and proposed an extensive document. I’m not jumping into discussions handwaving a couple of buzzwords.
If your PEP defends against all the attacks TUF does, then it will be just as complicated as TUF. If it doesn't defend against all those attacks, then it offers even less justification for the complexity increase than TUF. >> If you add a threat model to the draft PEP, then we can have a useful discussion, > > There is a whole section called "threat model”. If you would like to see the threat model extended to cover different attacks, I reckon there’s a less aggressive way to phrase your opinion. My apologies, it is customary to explain the threat model *before* proposing a solution to it, and I did indeed lose patience before reaching that part of the PEP. I have now read that section, and still find it lacking compared to the comprehensive threat analysis research backing TUF. Note that, as with Donald, I have no problem with the idea of improving PyPI's account authentication mechanisms. That's purely a matter of any other major PyPI enhancements being behind the Warehouse migration in the priority queue, and can be addressed without a PEP. It's the proposed bespoke package signing and trust management system I am sceptical of. >> 1. People like Donald, Ernest, Richard Noah (i.e. PyPI and infrastructure admins) are part of the threat model for PEP 458. How does your PEP defend against full compromise of those accounts? > > It doesn’t, nor PEP 458 does. If an attacker owns a root shell on PyPI, it is game over with both PEPs; that is, unless you’re referring to the claimed role for which PEP 458 is severely lacking the most important and hard thing: how to populate it. PEP 458 includes both offline root keys and an "N of M" signing model specifically so compromise of a single administrator account can't break the whole system (aside from DoS attacks). >> 2. What level of damage mitigation are we aiming to attain in the event of a full PyPI compromise? (i.e. attacker has full control over absolutely everything published from PyPI) > > I’m not sure I understand the question or how it differs from the previous one. The thread model section on "PyPI server compromise” in my PEP has some details though. And it amounts to minimal additional defence beyond where we are today. >> >> 3. Assuming an attacker has fully compromised DNS and SSL (and hence can manipulate or replace *all* data purportedly being received from PyPI by a given target), what additional level of integrity is the "end-to-end" signing process adding? > > In all cases in which the trust file is cached / edited with no automatic updates, it fully guarantees that no compromised packages can be installed in the user machine. This wouldn’t be the standard setup for most users. Except it allows known-vulnerable versions to be installed. > > If you’re willing to think that this an important use-case (in my opinion, it’s quite far from it), I can revise my PEP to add for an offline signing like the “claimed role” in PEP 458; that’s a very simple addition, as the hardest part is totally elsewhere (= how you setup such an offline process with the PSF staff and resources). I could also explore how to better integrate my PEP with a peep-like solution, that is an automatic caching of the subset of the trust file, connected somehow to the project-specific requirements.txt (but see below for differences). Now you're getting to one of the key reasons TUF integration stalled: the requirement for offline root keys is there for good reason, but it's a hard data management problem for a distributed administration team. >> 4. What level of guarantee will be associated with the signing keys, and are package authors prepared to offer those guarantees? (The only dev community I've really talked to about that is a few of the Django core devs, and their reaction was "Hell, no, protecting and managing keys is too hard”) > > If package authors are unwilling to handle signing keys, PEP 458 is also doomed, and moreso since it would use an obscure, custom, one-purpose signing key and key tools, with no extensive documentation on proper handling on multiple operating systems and development scenarios. I thus don’t see how this question is pertinent in evaluating my PEP vs PEP 458. The signing algorithm isn't the interesting part of TUF - it's the key management and trust delegation. This question is relevant to both proposals, as the case where PyPI is signing on behalf of the developer is a critical one to handle in order to keep barriers to entry low. A "solution" that leads to end users just turning off signature checking (because most packages aren't signed) is undesirable, as it means missing out on the additional integrity checks for the PyPI-user link, even if those packages are still vulnerable to PyPI compromise. >> >> 5. How do these guarantees compare to the much simpler SSH inspired "trust on first use" model already offered by "peep"? > > I’m not very familiar with peep, but my understanding is that it doesn’t help at all for package upgrades; if an attacker compromises the latest release of Django, any user installing that release for the first time in each virtualenv wouldn’t realize it. peep is designed to be used in conjunction with version pinning - upgrades happen deliberately rather than implicitly. > Any package signing solution (both PEP458 and my PEP) fixes this, as creates a trust path that can be used to install multiple files. Yes, the challenge is to create such a trust path in a way that it *adds* significantly to the security offered by SSL, rather than being vulnerable to the same classes of attacks. Regards, Nick. > > -- > Giovanni Bajo :: ra...@develer.com > Develer S.r.l. :: http://www.develer.com > > My Blog: http://giovanni.bajo.it > > > > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
