On Mon, Nov 19, 2012 at 4:34 PM, Tarek Ziadé <ta...@ziade.org> 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 ? > You should consider reading up on the design of TUF: The Update Framework ( https://www.updateframework.com/). They have designed a security system for Python packages. One solution to the key revocation problem is to have two signatures, a timestamp from PyPI along with a signature from the publisher. The package is only valid if it has a valid publisher signature along with a timestamp that is within the validity period of the publisher's signing key. In other words, if I publish a package in October but revoke my public key in November, the package is still valid because PyPI asserts it was signed before the key was revoked.
_______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
