On Tue, Nov 13, 2012 at 12:23 PM, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de" target="_blank">martin@v.loewis.de</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="im"><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">

I want to remove distutils from the standard library. If that happens<br>
then we might want a secure way to install it from pypi. One way would<br>
be to include the public key used to sign distutils in Python's own<br>
signature-verifying bootstrap wheel installer, never mind whether it<br>
used ECDSA or RSA or Ed25519. Do you have a better idea? TUF?<br>
<a href="https://www.updateframework.com/wiki/SecuringPythonPackageManagement" target="_blank">https://www.updateframework.<u></u>com/wiki/<u></u>SecuringPythonPackageManagemen<u></u>t</a><br>
</blockquote>
<br></div>
It depends on the threat model - whose definition is key to any security<br>
discussion.<br>
<br>
I'd say that providing the CA certificate of the CA, and to use https<br>
for downloading, should be enough.<br>
<br>
Alternatively, if the threat is that somebody may have hacked PyPI,<br>
then hard-code the hash (SHA-3 if you are paranoid) in the Python<br>
distribution, and rely on downloading a specific version from PyPI.<br>
<br>
OTOH, I'm -1 on removing the code from Python in a way that it may<br>
come back through downloading. Instead, it is much easier to keep<br>
it included.<br></blockquote><div><br></div><div>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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>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 <a href="https://bitbucket.org/dholth/pep425tags/">https://bitbucket.org/dholth/pep425tags/</a> ? 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.</div>
<div><br></div><div>distutils itself is not testable.</div><div><br></div><div>Daniel Holth</div></div></div>