[Distutils] PEP draft on PyPI/pip package signing
graffatcolmingov at gmail.com
Tue Jul 29 03:50:15 CEST 2014
On Mon, Jul 28, 2014 at 8:12 PM, Giovanni Bajo <rasky at develer.com> wrote:
> Il giorno 29/lug/2014, alle ore 02:39, Nick Coghlan <ncoghlan at gmail.com> ha
> 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. 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.
> 1) TUF isn’t designed for PyPI and pip. It’s a generic system meant for many
> different scenarios, which is then adapted (with many different compromises)
> to our use case. So you can’t really postulate that you absolutely need
> something as complicated to get to the same level of defense.
> 2) Security is never perfection. You might very well decide that the
> increased level of security is not worth the complexity increase.
> My solution is far far simpler than TUF. To me, it’s a reasonable compromise
> between complexity of implementation, time/costs required for all involved
> parties, and decreased security.
While there's a significant difference between the complexity of the
proposals to implement, there's also a significant difference in
complexity for the end users.
On the one hand, to implement PEP458, would mean a great deal of work
on those working on PyPI/Warehouse and pip, but it would have little
(if any) end user implications or complications.
Your PEP on the other hand, causes some instabilities (especially if
PGP/GPG isn't installed, or if someone has hijacked the PATH) and will
create only headaches for the users. They'll have to install GPG,
generate a Key, upload the key, secure the key, and make sure they
don't ever lose it. While there's less complexity for the
implementers, there's much more for end users. We don't want to make
packaging worse for users in exchange for a negligible (questionable?)
amount of increased security.
>>> If you add a threat model to the draft PEP, then we can have a useful
>> 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.
> If it’s only “lacking", then i’m happy, as that PEP is not my PhD
> dissertation :)
>>> 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).
> It depends on your definition of “compromise of a single administrator”.
> Obviously if you compromise the root signing key, then yes, the N/M model
> helps, but that key doesn’t exist in my PEP in the first place (which means
> that my PEP is simpler, requires less work on administrators, less key
> management, etc.). If with “compromise of an administrator” you intend that
> an attacker can login into PyPI and become root, than I maintain that PEP458
> and my PEP are mostly equivalent, in that they offer close to no protection;
> the attacker can compromise all packages.
> PEP458 then has this “claimed” role that is signed with an offline key,
> which would protect from a PyPI compromise, and which Donald says it’s the
> only reason he cares about PEP458. But it totally punts on how to maintain
> that role from a practical standpoint; how do you move projects into there?
> How do verify author keys (and identities)? How do you handle the offline
> verifications of keys from maintainers all over the world? Should the PSF
> setup a telephone line for that? Should outsource some identity verification
> to an external company? How do you protect from different kind of social
> engineering? I did some researches on the topic a couple of years ago, and
> it’s a very tough topic. Having the software part that can handle offline
> signing is the easiest part.
>>> 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.
> Yes. I don’t claim otherwise either.
>>> 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.
> Well, known-vulnerable versions are a problem in deployments, not
> development. If you’re fully compromising DNS and SSL of a deployment
> machine, there are far easier way to attack your target. Moreover, in
> deployments, most people do fix versions of packages they install. I don’t
> think anybody is running deployments in which they install whatever latest
> version of Django PyPI serves them. In that case, serving a different
> version would still make pip abort installation.
> Protecting development machines against code execution is fully achieved by
> my PEP with a manually-edited (or peep-like edited) trust file.
>>> 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.
> you don’t need to turn off signature checking, you can simply allow
> installation of packages with missing GPG signatures. So again, if
> developers refuse to touch keys, you’re not affecting security of users
> installing signed packages.
>>> 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.
> yes, but WHEN upgrades do happen, peep offers no security; instead, my
> proposal does offer security in that the new never-seen-before package can
> still be checked for authentication (through the signature).
> Giovanni Bajo :: rasky at develer.com
> Develer S.r.l. :: http://www.develer.com
> My Blog: http://giovanni.bajo.it
> Distutils-SIG maillist - Distutils-SIG at python.org
More information about the Distutils-SIG