Il giorno 14/feb/2013, alle ore 12:00, Ronald Oussoren <ronaldousso...@mac.com> ha scritto:
> > On 14 Feb, 2013, at 11:25, Nick Coghlan <ncogh...@gmail.com> wrote: > >> On Thu, Feb 14, 2013 at 6:46 PM, Ronald Oussoren <ronaldousso...@mac.com> >> wrote: >>> >>> On 13 Feb, 2013, at 15:21, Nick Coghlan <ncogh...@gmail.com> wrote: >>>> >>>> >>>> For now, though, we would probably start off with >>>> release/target/timestamp roles sharing a key, all threshold values set >>>> to 1, and just doing simple project based target delegation to user >>>> keys. Given the existing GPG infrastructure, I'm also inclined to >>>> stick with GPG based keys and work with the TUF folks to define that >>>> format in their spec. We may also need to leave the protection against >>>> replay attacks off by default, do to the problem with incorrect clocks >>>> noted at the end of the TUF spec. >>> >>> On the other hand, AFAIK the GPG infrastructure of PyPI isn't used a lot >>> and OpenSSL exposes PCKS#1 which means those can be used without adding new >>> dependencies to CPython, and likely without installing new software on all >>> unix-like systems (the openssl command-line tool is available on both osx >>> and all linux boxes I checked). For 3.4 the PCKS#1 support in openssl >>> could be exposed through a new extension module. >>> >>> I don't have preferences either way, >> >> I believe the main challenge in either case is Windows. For GPG, the >> suggestion is for the pip folks to figure out a way to bundle GPG >> (which has its own problems), but there's no current suggested Windows >> approach for PCKS#1. I wonder if a way could be found to retrieve it >> from CPython's bundled OpenSSL on Windows? > > On first glance OpenSSL seems to be staticly linked into the _ssl extension > (there is no openssl DLL on my windows machine with Python 2.7), and the > openssl command-line tool is not installed either. Unless we'd be very lucky > this means that the pip (and distutils/setuptools/...) folks would have to > bundle an openssl binary for use on Windows when using OpenSSL as well. > > Still, the license of OpenSSL is likely more amendable to bundling than the > GPG. But as you said, using GPG would with some luck make it possible to use > distutils in current releases of Python to upload to the secure version of > PyPI. To clarify, current versions of distutils can't securely upload to PyPI, because they don't hardcode the HTTPS URL. If you redirect from the server side, they can still be MITM'd though a SSL stripping attack. In my proposal, this is taken into account by task #11 "Allow passwordless uploads of signed packages". The idea is that, since all packages would eventually GPG signed, and the GPG fingerprint is already known to PyPI, it might be possible to allow package uploads without any form of further authentication. This means that, once implemented, we can teach maintainers to simply not enter any password while doing "setup.py upload" with an old, unpatched version of distutils that asks for it. This technically could be done with TUF as well, but of course there is no current version of distutils that integrates it, so in that case we still need to provide new command line tools to all maintainers, as far as I can tell. PS: please notice that OpenSSL does not contain any key management workflow or protocol; it is left to the good will of the user to safely store secret keys, with passphrases, publish them, and let people know they are revoked. GPG handles all of this, and also integrates native GUI tools for keychain management, file encryption, and whatnot. -- Giovanni Bajo :: ra...@develer.com Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
