Il giorno 07/feb/2013, alle ore 23:26, Nick Coghlan <[email protected]> ha 
scritto:

> 
> On 8 Feb 2013 02:43, "Giovanni Bajo" <[email protected]> wrote:
> >
> > Il giorno 07/feb/2013, alle ore 17:21, Donald Stufft 
> > <[email protected]> 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   ::  [email protected]
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

Reply via email to