On 7 Feb, 2013, at 11:25, Giovanni Bajo <ra...@develer.com> wrote: > Il giorno 07/feb/2013, alle ore 11:08, Ronald Oussoren > <ronaldousso...@mac.com> ha scritto: > >> >> On 6 Feb, 2013, at 22:15, Daniel Holth <dho...@gmail.com> wrote: >> >>> On Wed, Feb 6, 2013 at 4:05 PM, Jesse Noller <jnol...@gmail.com> 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.
I agree. The primary reason to mention a python implementation is that PGP/GPG shouldn't be excluded just because it is an external C tool and not a 3 line python algoritm. > >> 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. The system should also be somewhat userfriendly, having to accept a new key for every package will likely not increase security as much as it would seem at first glance because a lot of users will just accept the new key without seriously looking at it. What I'd like to see is a system where I can be reasonably sure that when I do "<tool> install <package>" I'll get that package (and its dependencies) of PyPI, without a MITM interfering and with some assurance that the package is uploaded by an authorized user and the contents is what that user wants it to be. Anything beyond that, such explicitly trusting individual developers might be useful in the long run but has a clear risk of making package installation more complicated. It would be nice if the system uses well established protocols instead of green-field development. I know just enough of security systems to be dangerous, and one thing I do try to keep in mind when I do have to do anything security related is that it is a lot easier to create almost-but-not-quite secure protocols/architectures than actual secure ones. Ronald > -- > Giovanni Bajo :: ra...@develer.com > Develer S.r.l. :: http://www.develer.com > > My Blog: http://giovanni.bajo.it > > > > >
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
