[Catalog-sig] [Draft] Package signing and verification process

Giovanni Bajo rasky at develer.com
Thu Feb 7 23:33:56 CET 2013


Il giorno 07/feb/2013, alle ore 23:26, Nick Coghlan <ncoghlan at gmail.com> ha scritto:

> 
> On 8 Feb 2013 02:43, "Giovanni Bajo" <rasky at develer.com> wrote:
> >
> > Il giorno 07/feb/2013, alle ore 17:21, Donald Stufft <donald.stufft at gmail.com> ha scritto:
> >
> >> On Thursday, February 7, 2013 at 10:50 AM, Giovanni Bajo wrote:
> >>
> >> 1. If we're going to implicitly trust PyPI when it says that key X is valid for package Y,
> >>     do we really gain much here? If we're trusting PyPI then we only really need secure
> >>     ingress and egress neither of which need packaging signing.
> >
> >
> > Adding GPG signature on top of SSL helps mitigating (at least) the following concerns:
> >
> > 1) If a PyPI account password is compromised (stolen, bruteforced, etc.), an attacker cannot upload a package that will be installed by package managers. This also requires making sure that a GPG fingerprint cannot be added to the account without a second factor authentication (can be anything from a link to a security email address, to a SMS). Notice that PyPI passwords are currently saved in the filesystem in clear ($HOME/.pypirc).
> 
> Which reminds me, that system *really* should be replaced/supplemented with a time limited server generated auth token, the way Bugzilla and various other services do it.
> 

I don't know if the password stored in .pypirc is used for something else, but in my future vision, "setup.py upload" will not really require authentication: once all maintainers have a GPG key generated and associated with their PyPI account, uploading a new package doesn't require any password-based authentication, since the signature itself already authenticates the maintainer.

Anyway, an intermediate solution based on a OTP will still be needed in all the transition period (or forever, if we end up not agreeing on forcing GPG).
> If need be, I can bug a couple of GPL RH projects to contribute their existing solutions to that problem, but there should be non-GPL examples kicking around the web already
> 

I'm not sure there is much code that can be reused there; the server generates a random passkey, stores in the DB, and authenticates against it on connection (in addition to the normal password). I havent' looked at the PyPI source code yet, but unless it's using a standard mainstream web framework like Django, for which we might find some drop-in code as an "app", I don't think there can be much reuse.
-- 
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/catalog-sig/attachments/20130207/182a9c96/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/182a9c96/attachment.bin>


More information about the Catalog-SIG mailing list