In the light of Ruby's recent issues and man in the middle attacks on PyPI (http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_untrusted_network_a/) we should include secure uploads in distutils.

Martin has created a SSH uploader for distutils http://pypi.python.org/pypi/pypissh. I suggest that we include the feature in the next security update for Python 2.6 to 3.3. I'm well aware that this beats the "no new feature" clause but in my opinion "security beats purity".

What do you think?

> Martin has created a SSH uploader for distutils
> http://pypi.python.org/pypi/pypissh. I suggest that we include the
> feature in the next security update for Python 2.6 to 3.3. I'm well
> aware that this beats the "no new feature" clause but in my opinion
> "security beats purity".

"this package performs heavy monkey-patching of distutils to make it
use the system's ssh command. Users using this package should run
ssh-agent (which runs automatically in the background on many systems)
and load their PyPI key into the ssh agent."

I don't think this bodes well for immediate inclusion, especially in
a bugfix release. Perhaps some time should be taken to clean it up
and then include it in 3.4.

I'm still not sure why this would be better than HTTPS upload, though.

Python 2.6 to 3.1 don't do HTTPS server cert validation. This leaves the upload process open to MITM attacks ...

I would strongly prefer to back port certificate validation instead. Is there anything *practical* that makes it hard/impossible?

If we want to keep features stable, we can add it privately so it’s only usable by distutils. The susceptibility to (easy!) MITM attacks can be counted as a security bug and this seems the most practical resolve.

+1 for back porting SSL validation even if it's a private to distutils backport.

pypissh requires a SSH Binary which isn't all that great on Windows where SSH is not typically installed by default.

Infrastructure needs to get a proper SSL cert first and we have to ship the CA's public key so we can verify the cert everywhere.

Well Infrastructure *should* get a proper cert anyways else MITM is trivial via the web interface anyways.

PyPI *has* a proper cert, it's just not in the default trusted certs of most distributions and browsers (i.e., it uses CACert). It would be easy to bundle CACert's root cert with distutils, if we wanted to.

CACert is not *proper* irregardless of what that projects goals are. It is not trusted by default therefore it does not provide the same level of security in the browser (Very few people will bother to look at the difference between a CACert and a self signed cert). Further more I don't believe you'll be able to use HSTS with it at all making SSL Stripping a very easy avenue to a MITM.

And there is OCSP. I'm getting sec_error_ocsp_invalid_signing_cert for https://pypi.python.org/pypi. I haven't been able to do a successful HTTPS request from Firefox to PyPI all day.

Wow. Can we calm down? Setting many feature requests as release blockers certainly won't magically solve issues.

Benjamin requested that I should set the priority of all tickets to 'release blocker' that needs be be addressed, discussed and possibly fixed for the upcoming releases.

Yes, and why do you think this should be addressed in the next bugfix release? If HTTPS is so broken that you can't upload important data with it, then perhaps patching Python is not the most important thing to do?

In other words: don't you think you're overreacting?

Perhaps a tiny bit. ;) My brain is in paranoid mode ...

Too much of a new feature IMO.

Python 2.6 can get remote certificate and compute a hash of it, and compare that hash with a known fingerprint. This is what mercurial does.

No proper certificate chain, but secure as far as the PYPI certificate doesn't change.

This would be not a "final" solution, but it is a tiny patch and far safer than current approach.

Then cross fingers for PYPI certificate stability :-).

> "this package performs heavy monkey-patching of distutils to make it
use the system's ssh command."
> I don't think this bodes well for immediate inclusion, especially in
a bugfix release.

It only needs monkey-patching to convince distutils to connect over ssh. This is suggesting it handle it natively. (clearly)

SSH upload is an acceptable new feature for Python 3.4, if it can be done without breaking compat or changing too many internals.

(The distutils feature freeze was effectively lifted at PyCon; Nick Coghlan also has a PEP in the plans to discuss how to update distutils for new packaging standards.)

I retract my proposal. We don't need ssh upload any more.