On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg <mal@egenix.com> wrote:
On 13.11.2012 10:51, "Martin v. Lwis" wrote:
> Am 13.11.12 03:04, schrieb Nick Coghlan:
>> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth@gmail.com
>> <mailto:dholth@gmail.com>> wrote:
>>
>> I think Metadata 1.3 is done. Who would like to czar?
>>
>> (Apologies for the belated reply, it's been a busy few weeks)
>>
>> I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
>> with some additional rationale based on Ronald's comments later in this
>> thread, though.
>
> For the record, I'm still -1 on PEP 427, because of the signature issues.
>
> The FAQ in the PEP is incorrect in claiming PGP or X.509 cannot
> readily be used to verify the integrity of an archive - the whole
> point of these technologies is to do exactly that.
>
> The FAQ is entirely silent on why it is not using a more standard
> signature algorithm such as ECDSA. It explains why it uses Ed25519,
> but ignores that the very same rationale would apply to ECDSA as well;
> plus that would be one of the standard JWS algorithms.
>
> In addition, the FAQ claims that the format is designed to introduce
> cryptopgraphy that is actually used, yet leaves the issue of key
> distribution alone (except that pointing out that you can put them
> into requires.txt - a file that doesn't seem to be specified anywhere).

I agree with Martin. If the point is to "to protect against cryptography
that is not used", then not using the de-facto standard in signing
open source distribution files, which today is PGP/GPG, misses that
point :-)

Note that signing such distribution files can be handled outside
of the wheel format PEP. It just way to complex and out of scope
for the wheel format itself. Also note that PGP/GPG and the other
signing tools work well on any distribution file. There's really no
need to build these into the format itself.

It's a good idea to check integrity, but that can be done using
hashes.

PGP-on-pypi is the very definition of cryptography that isn't used.

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.

Is the rest of the wheel specification, explaining how packages are actually produced and installed, clear?


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? https://www.updateframework.com/wiki/SecuringPythonPackageManagement