On Feb 7, 2013, at 5:25 AM, Giovanni Bajo <[email protected]> wrote:
> Il giorno 07/feb/2013, alle ore 11:08, Ronald Oussoren > <[email protected]> ha scritto: > >> >> On 6 Feb, 2013, at 22:15, Daniel Holth <[email protected]> wrote: >> >>> On Wed, Feb 6, 2013 at 4:05 PM, Jesse Noller <[email protected]> wrote: >>>> >>>> >>>> On Wednesday, February 6, 2013 at 4:02 PM, Donald Stufft wrote: >>>> >>>> > On Wednesday, February 6, 2013 at 4:01 PM, Vinay Sajip wrote: >>>> > > M.-A. Lemburg <mal <at> egenix.com (http://egenix.com)> writes: >>>> > > >>>> > > > Try gnupg-w32cli which is really easy to install and doesn't >>>> > > > get in your way: >>>> > > > >>>> > > > http://lists.gnupg.org/pipermail/gnupg-announce/2012q1/000313.html >>>> > > >>>> > > Or, to fast-track to the binaries, look in here: >>>> > > >>>> > > ftp://ftp.gnupg.org/gcrypt/binary/ >>>> > > >>>> > > As MAL says, installation with these installers is fairly painless. >>>> > Average end user: "What's a GPG" >>>> >>>> Or even those of us familiar and using it day to day "Oh Jeez not again" >>> >>> That is why the original wheel signing design uses no GPG, a system that >>> has proven to be unused in practice. Hypothesis: something different cannot >>> possibly be less successful. Instead, it uses raw public key signatures >>> implemented with very concise Python code. It might even automatically >>> generate one for you if you have none. Wheel's scheme would be perfect for >>> Plone which distributes long lists of all its dependencies, as they would >>> just add the publisher key as an argument to each dependency. A new >>> maintainer might receive a copy of the private key as keys are meant to be >>> plentiful and contain no extra information such as e-mail addresses. >>> >>> Using ssh-agent to produce signatures with the user's ssh keys is another >>> option. >>> >>> There is a complete Python implementation of TLS out there. >> >> Implementing enough of PGP in python to do clear signing and verification >> shouldn't be too hard either :-) > > I'm -1 on that; installing GPG is easy on all major development platforms > (including Windows), and we can provide a simple tutorial for the few > required steps. That tutorial would have to be amazingly easy, and GPG could never be a hard requirement. GPG is still annoying, clunky and painful enough that it would just become a nuisance and people would move elsewhere. So adding support? Ok; but it would have to be optional and not mandatory. I'd rather finish the ssl certs first, and get hashes upgraded from md5 to sha-256 and getting clients to enforce those just to start > >> What I haven't seen (or have overlooked) in the entire discussion is what >> we're trying to protect against. The thread kicked of due to a report of >> how to perform MITM attacks against PyPI, but it seems that some of the >> proposals want to provide much more security than that. Without a clear >> description of a threat model it is hard to evaluate if proposals actually >> fix anything. > > Basically, we are trying to define a system that can survive some level of > compromisation of PyPI, and at the same time allow PyPI to use a third-party > CDN without having to trust it. > > Moreover, some people might want to get to a point where they disable trust > on PyPI totally but they still want to be able to install packages off it. > -- > Giovanni Bajo :: [email protected] > Develer S.r.l. :: http://www.develer.com > > My Blog: http://giovanni.bajo.it > > > > > > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
