classification
Title: SSH upload for distutils
Type: enhancement Stage: resolved
Components: Distutils Versions: Python 3.4
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: barry, benjamin.peterson, christian.heimes, dstufft, eric.araujo, georg.brandl, gvanrossum, hynek, jcea, jwilk, larry, loewis, pitrou, tarek, tom.prince
Priority: normal Keywords:

Created on 2013-02-04 10:03 by christian.heimes, last changed 2016-09-08 22:43 by christian.heimes. This issue is now closed.

Messages (19)
msg181313 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 10:03
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?
msg181314 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-02-04 10:24
> 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.
msg181315 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 10:32
Python 2.6 to 3.1 don't do HTTPS server cert validation. This leaves the upload process open to MITM attacks ...
msg181317 - (view) Author: Hynek Schlawack (hynek) * (Python committer) Date: 2013-02-04 12:03
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.
msg181323 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2013-02-04 12:58
+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.
msg181324 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 13:00
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.
msg181326 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2013-02-04 13:13
Well Infrastructure *should* get a proper cert anyways else MITM is trivial via the web interface anyways.
msg181337 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-02-04 15:49
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.
msg181343 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2013-02-04 16:19
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.
msg181345 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 16:25
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.
msg181374 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-02-04 18:59
Wow. Can we calm down? Setting many feature requests as release blockers certainly won't magically solve issues.
msg181377 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 19:21
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.
msg181378 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-02-04 19:23
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?
msg181381 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-02-04 19:34
Perhaps a tiny bit. ;) My brain is in paranoid mode ...
msg181384 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-02-04 20:00
Too much of a new feature IMO.
msg181405 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2013-02-05 02:53
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 :-).
msg191177 - (view) Author: Tom Prince (tom.prince) Date: 2013-06-15 00:21
> "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)
msg191361 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-06-17 18:54
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.)
msg275195 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-08 22:43
I retract my proposal. We don't need ssh upload any more.
History
Date User Action Args
2016-09-08 22:43:05christian.heimessetstatus: open -> closed
resolution: wont fix
messages: + msg275195

stage: needs patch -> resolved
2013-06-19 13:02:38jwilksetnosy: + jwilk
2013-06-17 18:54:02eric.araujosettype: security -> enhancement
messages: + msg191361
versions: - Python 2.7
2013-06-15 00:21:21tom.princesetnosy: + tom.prince

messages: + msg191177
versions: + Python 2.7
2013-02-05 02:53:33jceasetmessages: + msg181405
2013-02-05 02:47:26jceasetnosy: + jcea
2013-02-04 22:15:40eric.araujosetversions: - Python 2.6, Python 2.7, Python 3.2, Python 3.3
2013-02-04 21:30:22gregory.p.smithsetnosy: - gregory.p.smith
2013-02-04 20:00:29benjamin.petersonsetpriority: release blocker -> normal

messages: + msg181384
2013-02-04 19:34:50christian.heimessetmessages: + msg181381
2013-02-04 19:23:50pitrousetmessages: + msg181378
2013-02-04 19:21:08christian.heimessetmessages: + msg181377
2013-02-04 18:59:33pitrousetmessages: + msg181374
2013-02-04 17:11:01christian.heimessetpriority: critical -> release blocker
nosy: + larry, barry, benjamin.peterson, georg.brandl
2013-02-04 16:25:17christian.heimessetmessages: + msg181345
2013-02-04 16:19:34dstufftsetmessages: + msg181343
2013-02-04 15:49:56pitrousetmessages: + msg181337
2013-02-04 13:13:36dstufftsetmessages: + msg181326
2013-02-04 13:00:29christian.heimessetmessages: + msg181324
2013-02-04 12:58:47dstufftsetnosy: + dstufft
messages: + msg181323
2013-02-04 12:03:51hyneksetnosy: + hynek
messages: + msg181317
2013-02-04 10:32:05christian.heimessetmessages: + msg181315
2013-02-04 10:24:45pitrousetmessages: + msg181314
2013-02-04 10:03:42christian.heimescreate