ez_setup using wget fails when SSL cannot be verified

[ghost]

Originally reported by: s0undt3ch (Bitbucket: s0undt3ch, GitHub: s0undt3ch)

---

Some versions of wget require extra arguments for proper downloads over HTTPS

#!text
# wget https://pypi.python.org/packages/source/s/setuptools/setuptools-1.1.tar.gz --output-document /tmp/foo
--2013-08-31 09:46:08--  https://pypi.python.org/packages/source/s/setuptools/setuptools-1.1.tar.gz
Resolving pypi.python.org... 199.27.74.184, 199.27.74.185
Connecting to pypi.python.org|199.27.74.184|:443... connected.
ERROR: certificate common name `*.a.ssl.fastly.net' doesn't match requested host name `pypi.python.org'.
To connect to pypi.python.org insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/75

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

The primary reason for using wget (and curl and powershell) is to perform SSL validation on the connection. The trace you sent indicates that the SSL validation failed, and in this case, we want ez_setup to fail. Otherwise, the download could be intercepted by a man-in-the-middle attack and the system could be compromised.

I'll have to file a ticket upstream (pypi) to ask about the host name mismatch, but as it stands, the behavior you described is expected and desirable.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I created PyPI 59 to inquire about and track the upstream issue.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

After further consideration and reviewing PR 16, I agree there's more that should be done. It shouldn't be the case that the ez_setup is unable to download the content, so there should be a bypass option (which will disable the secure downloaders and simply fall back to the insecure, internal downloader).

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

ez_setup.py now takes a --insecure argument to bypass the secure downloaders. download_setuptools also now accepts a new keyword argument 'download_factory', enabling programmitic invocation to customize the downloader resolution. Fixes #75. Thanks to Pablo Algarvio for the report and suggestions.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I've updated the 'bootstrap' bookmark to point to the updated script. The command-line option is "--insecure" instead of "--insecure-https" as in the pull request. Please try that out and confirm this addresses the issue.

[ghost]

Original comment by s0undt3ch (Bitbucket: s0undt3ch, GitHub: s0undt3ch):

---

--insecure works perfectly

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Issue #106 was marked as a duplicate of this issue.

[ghost]

Original comment by apshoemaker (Bitbucket: apshoemaker, GitHub: apshoemaker):

---

Can you please add this to the setup install instructions? I got hit with this today and had to dig into this thread to find the solution.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

@apshoemaker Sorry for the delayed response. I'd accept a PR in this vein.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

Issue #282 was marked as a duplicate of this issue.