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.
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
