On 19.11.2012 22:34, Tarek Ziadé wrote: > On 11/19/12 7:55 PM, M.-A. Lemburg wrote: >> On 19.11.2012 19:37, Tarek Ziadé wrote: >>> Hey >>> >>> >>> I am currently writing a small script to verify that the gpg signature is >>> correct when the --sign >>> option >>> is used with the Distutils upload command, and I was wondering why we don't >>> publish the public key >>> alongside the .asc file. >>> >>> Right now, unless I missed something, to verify a signature the user has to >>> manually get the public >>> key before she >>> can control the tarball. >>> >>> Wouldn't it make sense to modify the upload command and add a .pubkey file >>> alongside the archive >>> file >>> and the .asc file on PyPI ? (since we don't have a notion of team/users >>> etc.) >> >> Doesn't that cause problems when revoking a public key ? >> > That problem still exists as things are today at PyPI -if you sign a package > you get an .asc file > uploaded and > you need to tell people where is your public key. > > If you change your key, the asc file is not valid anymore. > > I am not sure what would be the best way to do this: maybe we should allow > people to update the asc > files ?
There are two things to consider when revoking a key (e.g. because it got compromised): 1. You need to tell users that the key is revoked 2. You need to be able to resign packages that had been signed using the revoked key. For the first requirement, I think PyPI should not try to create a new PKI, but instead rely on the existing public key servers that PGP and GPG both know how to work with. Key revocation is part of this infrastructure, along with many other features that we don't really want to duplicate in PyPI :-) For the second requirement, updating the .asc file would be a solution. Alternatively, the packagers could check the revocation date and then still allow packages to be installed which were signed before the revocation happened. Note that the second requirement may also be needed for expired keys - unless packagers choose to ignore such expiration, and accept packages that were signed with a then valid key. This is how Windows treats expired certificates on installers. For both methods involving checking the packaging time, you do need to use a timestamp server to make things waterproof (see e.g. http://stackoverflow.com/questions/2872105/alternative-timestamping-services-for-authenticode). Aside: These discussions appear a bit academic to me, since the signatures only add a small bit of extra security to the whole setup (protection against tampering with the distribution files on the PyPI server and an extra password entry on the uploader's side), while making the system a lot more complex. Apart from the academic challenge, I wonder whether it's worth the trouble :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 20 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
