<p dir="ltr"><br>
On 21 Feb 2013 06:57, "Donald Stufft" <<a href="mailto:donald.stufft@gmail.com">donald.stufft@gmail.com</a>> wrote:<br>
><br>
> On Wednesday, February 20, 2013 at 3:50 PM, Daniel Holth wrote:<br>
>><br>
>> Bikeshed detected.<br>
><br>
> Basically.<br>
><br>
> We basically can't use any of the properties of the various signing techs besides<br>
> their ability to sign documents so the choice of them doesn't particularly matter.<br></p>
<p dir="ltr">Not *quite* true - GPG comes with more mature client side tech for managing signing keys at the developer end, and that's independent of the PyPI trust model. Since it's a coin flip otherwise, that's probably going to be enough for us to favour GPG as the signing tech.</p>

<p dir="ltr">In the spirit of "status quo wins a stalemate", GPG should currently be considered the default choice, with alternatives needing to offer genuinely compelling advantages to displace it. (note that isolating the signature generation and verification to a separate non-Python process isn't a major issue from my point of view)</p>

<p dir="ltr">Cheers,<br>
Nick.<br>
><br>
><br>
> _______________________________________________<br>
> Catalog-SIG mailing list<br>
> <a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/catalog-sig">http://mail.python.org/mailman/listinfo/catalog-sig</a><br>
><br>
</p>