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

Donald Stufft donald at stufft.io
Wed Dec 31 19:42:27 CET 2014

> On Dec 31, 2014, at 1:04 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 31 December 2014 at 17:43, Vladimir Diaz <vladimir.v.diaz at gmail.com> wrote:
>> PEP 480 includes a section that discusses a potential approach to packages
>> signed by package authors:
>> https://www.python.org/dev/peps/pep-0480/#automated-signing-solution
>> Let us know what you think.
> Thanks for the pointer. I read the section you referred to (admittedly
> in isolation). The language is unfamiliar to me, so I'm afraid I
> didn't get much from it. For example, I don't know what miniLock is,
> so that analogy was no help. Also, the phrase "the sharing of private
> keys across multiple machines of each developer" didn't mean much
> other than to raise alarms for me that I might not be able to simply
> log onto a new machine (a VM, for example, or a work machine) and do a
> quick "git clone; hack; python setup.py upload" to release an
> emergency fix, as I'd need a private key with me (as opposed to a
> password I can remember), and I'd needto do something to "allow key
> sharing" . That would be annoying.
> The "Enter a secondary password" note struck me as odd. Why would I
> need a *second* password? And why wouldn't I just reuse the same
> password as I use for PyPI? After all, I'm trusting that password
> hasn't been compromised, why make it harder on myself by needing to
> remember two passwords?

Just to speak to these two points. The purpose behind having a developer
sign some files is that you can verify that those files were signed by
the person holding the private key belonging to that developer.

In more traditional systems like RSA that key is pretty long, For example
here’s an RSA private key for TLS: https://github.com/python/psf-salt/blob/master/pillar/dev/secrets/tls/certs/loadbalancer.sls#L6-L33.

Obviously managing a file like that is kind of a pain and it prevents things
like being able to spin up a new VM quickly to make a release. Traditionally
only the author themselves have access to the private key so there’s no way
to get a copy from PyPI or something. The reason for this is that possession
of the private key is how you prove that you’re really the author.

One option is something called key escrow which essentially means that you
take your private key, encrypt it with a password and upload the encrypted
blob to PyPI. Then as long as your password is good and the encryption
algorithm is good it doesn’t matter if PyPI gets compromised because the
encrypted data isn’t able to be decrypted without the password known only
to the admin. The particular solution makes a lot of security folks nervous
only because if the password *is* bad or something does happen to break the
encryption algorithm it means that PyPI now has access to keys that it would
be preferential that it didn’t.

There are other signing algorithms, such as Ed25519 where the private keys can
be much shorter than in RSA. Ed25519 in particular requires only 32 bytes of
data for a private key. In addition to that there are particular algorithms that
can take an arbitrary number of characters (aka a user picked password) and derive
from that 32 bytes that can be used as the Ed25519 private key. This reduces
key management down to something as simple as “remember a second password” without
needing to resort to something like key escrow. Ideally you would not use the
same password as you use for logging into PyPI because you send that password to
PyPI anytime you login which would mean that PyPI would more or less know your
private key.

> Terminology-wise, I don't know what "adding a new identity" means. Is
> that authorising a second developer? Or could I need to have multiple
> "identities" myself? The first is fine, the second isn't (I'm me, why
> do I need to have 2 identities just to upload a distribution)?
> I'm aware of (and sorry about) the fact that this is very much a
> "drive by" scan of one section of the proposal in isolation. I *hope*
> it's still useful feedback, even if it's neither thorough nor
> particularly thoughtful - I was sort of aiming for "something is
> better than nothing", and that's all :-)
> Anyway, I'll leave further comment to people with a better
> understanding of the issue, although I'm happy to clarify if any of
> the above isn't clear.
> Paul.

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

More information about the Distutils-SIG mailing list