<div>
                    If you're going to build out the infrastructure for this it needs the ability for someone to
                </div><div>immediately (or within a very short timeframe) revoke their key. There is little value</div><div>in revoking a key (which could indicate that the original key was compromised) if</div><div>the unrevoked key is going to remain valid for a significant amount of time.</div><div><br></div><div><br></div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Monday, November 19, 2012 at 4:43 PM, Daniel Holth wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div><div>On Mon, Nov 19, 2012 at 4:34 PM, Tarek Ziadé <span dir="ltr"><<a href="mailto:tarek@ziade.org" target="_blank">tarek@ziade.org</a>></span> wrote:<br><blockquote type="cite"><div>
<div>On 11/19/12 7:55 PM, M.-A. Lemburg wrote:<br><blockquote type="cite"><div>
On 19.11.2012 19:37, Tarek Ziadé wrote:<br><blockquote type="cite"><div>
Hey<br>
<br>
<br>
I am currently writing a small script to verify that the gpg signature is correct when the --sign<br>
option<br>
is used with the Distutils upload command, and I was wondering why we don't publish the public key<br>
alongside the .asc file.<br>
<br>
Right now, unless I missed something, to verify a signature the user has to manually get the public<br>
key before she<br>
can control the tarball.<br>
<br>
Wouldn't it make sense to modify the upload command and add a .pubkey file alongside the archive file<br>
and the .asc file on PyPI ?  (since we don't have a notion of team/users etc.)<br>
</div></blockquote>
Doesn't that cause problems when revoking a public key ?<br>
<br>
</div></blockquote></div>
That problem still exists as things are today at PyPI -if you sign a package you get an .asc file uploaded and<br>
you need to tell people where is your public key.<br>
<br>
If you change your key, the asc file is not valid anymore.<br>
<br>
I am not sure what would be the best way to do this: maybe we should allow people to update the asc files ?<br></div></blockquote><div><br>You should consider reading up on the design of TUF: The Update Framework (<a href="https://www.updateframework.com/">https://www.updateframework.com/</a>). They have designed a security system for Python packages.<br>
<br>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.<br>
<br>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.<br><br><br></div></div></div>
</div><div><div>_______________________________________________</div><div>Catalog-SIG mailing list</div><div><a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/catalog-sig">http://mail.python.org/mailman/listinfo/catalog-sig</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>