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 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. > 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. > 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. > 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.
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). > 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. > 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. Any package signing solution (both PEP458 and my PEP) fixes this, as creates a trust path that can be used to install multiple files. -- Giovanni Bajo :: ra...@develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
