[Distutils] PEP draft on PyPI/pip package signing

[Nick Coghlan]

On 29 Jul 2014 10:01, "Giovanni Bajo" <rasky at develer.com> wrote:
>
> Il giorno 29/lug/2014, alle ore 01:36, Nick Coghlan <ncoghlan at gmail.com>
ha scritto:
>>
>> On 29 Jul 2014 03:43, "Giovanni Bajo" <rasky at 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   ::  rasky at develer.com
> Develer S.r.l.  ::  http://www.develer.com
>
> My Blog: http://giovanni.bajo.it
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140729/15826456/attachment.html>