> On Dec 31, 2014, at 1:04 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 31 December 2014 at 17:43, Vladimir Diaz <vladimir.v.d...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
