On Tue, Nov 13, 2012 at 12:23 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
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

It depends on the threat model - whose definition is key to any security
discussion.

I'd say that providing the CA certificate of the CA, and to use https
for downloading, should be enough.

Alternatively, if the threat is that somebody may have hacked PyPI,
then hard-code the hash (SHA-3 if you are paranoid) in the Python
distribution, and rely on downloading a specific version from PyPI.

OTOH, I'm -1 on removing the code from Python in a way that it may
come back through downloading. Instead, it is much easier to keep
it included.

It is a long term goal. It would be more practical to discourage distutils and encourage users to look elsewhere (Bento) for a beautifully designed build system.

The short term goal is just to standardize a way to install packages without having a build system, which is what wheel is for apart from the practical goal of simply installing lxml in a reasonable amount of time.

I think Metadata 1.2 (PEP 426) is ready to be accepted. The compatibility tags (PEP 425) need some additional text in the discussion section, any contributors for https://bitbucket.org/dholth/pep425tags/ ? Wheel (PEP 427) might mention that version 1.0 of the spec is only concerned with losslessly representing existing (setuptools & distutils) packages without trying to add too many new features apart from a standardized .egg substitute.

distutils itself is not testable.

Daniel Holth