On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg <span dir="ltr"><<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">On 13.11.2012 10:51, "Martin v. Lwis" wrote:<br>
> Am 13.11.12 03:04, schrieb Nick Coghlan:<br>
>> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a><br>
>> <mailto:<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>>> wrote:<br>
>><br>
>>   I think Metadata 1.3 is done. Who would like to czar?<br>
>><br>
>> (Apologies for the belated reply, it's been a busy few weeks)<br>
>><br>
>> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated<br>
>> with some additional rationale based on Ronald's comments later in this<br>
>> thread, though.<br>
><br>
> For the record, I'm still -1 on PEP 427, because of the signature issues.<br>
><br>
> The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot<br>
> readily be used to verify the integrity of an archive - the whole<br>
> point of these technologies is to do exactly that.<br>
><br>
> The FAQ is entirely silent on why it is not using a more standard<br>
> signature algorithm such as ECDSA. It explains why it uses Ed25519,<br>
> but ignores that the very same rationale would apply to ECDSA as well;<br>
> plus that would be one of the standard JWS algorithms.<br>
><br>
> In addition, the FAQ claims that the format is designed to introduce<br>
> cryptopgraphy that is actually used, yet leaves the issue of key<br>
> distribution alone (except that pointing out that you can put them<br>
> into requires.txt - a file that doesn't seem to be specified anywhere).<br>
<br>
</div></div>I agree with Martin. If the point is to "to protect against cryptography<br>
that is not used", then not using the de-facto standard in signing<br>
open source distribution files, which today is PGP/GPG, misses that<br>
point :-)<br>
<br>
Note that signing such distribution files can be handled outside<br>
of the wheel format PEP. It just way to complex and out of scope<br>
for the wheel format itself. Also note that PGP/GPG and the other<br>
signing tools work well on any distribution file. There's really no<br>
need to build these into the format itself.<br>
<br>
It's a good idea to check integrity, but that can be done using<br>
hashes.</blockquote><div><br></div><div>PGP-on-pypi is the very definition of cryptography that isn't used.</div><div><br></div><div><div>I'm willing to go ahead and move any mention of signing algorithms into a separate PEP, leaving only the basic manifest hash vs. file contents verification under the auspices of this PEP.</div>
<div><br></div><div>Is the rest of the wheel specification, explaining how packages are actually produced and installed, clear?</div></div><div><br></div><div><br></div><div>I want to remove distutils from the standard library. If that happens then we might want a secure way to install it from pypi. One way would be to include the public key used to sign distutils in Python's own signature-verifying bootstrap wheel installer, never mind whether it used ECDSA or RSA or Ed25519. Do you have a better idea? TUF? <a href="https://www.updateframework.com/wiki/SecuringPythonPackageManagement">https://www.updateframework.com/wiki/SecuringPythonPackageManagement</a></div>
</div></div>