[Python-Dev] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427

Daniel Holth dholth at gmail.com
Tue Nov 13 16:00:26 CET 2012


On Tue, Nov 13, 2012 at 5:26 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 13.11.2012 10:51, "Martin v. Löwis" wrote:
> > Am 13.11.12 03:04, schrieb Nick Coghlan:
> >> On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth <dholth at gmail.com
> >> <mailto:dholth at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121113/9b99dd27/attachment.html>


More information about the Python-Dev mailing list