Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable vendor C libraries on non-Windows platforms #4835

Merged
merged 15 commits into from
Mar 30, 2018

Conversation

pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Nov 4, 2017

Closes #4612 (this is that PR updated)
Closes #4098 (original issue)
Closes #4142 (competing PR)

This essentially allows users with Py <2.7.9 to fix security warnings by upgrading the relevant packages, using pip on non-Windows platforms.

@pradyunsg pradyunsg added type: enhancement Improvements to functionality type: security Has potential security implications project: vendored dependency Related to a vendored dependency labels Nov 4, 2017
@pradyunsg pradyunsg added this to the 10.0 milestone Nov 4, 2017
@pradyunsg
Copy link
Member Author

Some history:

@dstufft in #4098 (comment):

So this is a bit of a sticky issue. We've modified our bundled copies of the libraries so that they will not load any of the C libraries because on some OSs (particularly Windows) if pip imports the C library then it becomes impossible for pip to actually upgrade or uninstall that library (because importing locks the .dll from deletion). The downside of this is that it means you're stuck with what your Python is able to provide.

I see a few ways around this:

  1. Do nothing, let the warning's stand to try and push people to upgrade their Python to one that has a better SSL module.
  2. Disable the warnings completely, the warnings don't matter much for PyPI's own usage (although they could for non PyPI repositories) and just live with it.
  3. Adjust our disable of C libraries to only disable them on platforms where they cause problems (e.g. Windows).

@dstufft in #4098 (comment):

If someone makes a PR for (1) and (3) I would be happy to accept it

@alex in #4142 (comment):

Thing that just occurred to me: If pip starts supporting loading C-extensions again, we probably ought to make the openssl_version in the User-Agent reflect the version loaded by cryptography, not the one loaded by Python's ssl module.

@pradyunsg
Copy link
Member Author

I'm not sure what has to be done for the point that @alex raised.

My intuition is that all of pip's traffic goes through requests which would somehow use the correct user-agent. I've not verified this though.

@pradyunsg pradyunsg changed the title Vendoring/enable c libs Enable vendor C libraries on non-Windows platforms Nov 4, 2017
xavfernandez
xavfernandez previously approved these changes Nov 4, 2017
Copy link
Member

@xavfernandez xavfernandez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding @alex 's ssl-point this would happen here:

if HAS_TLS:
data["openssl_version"] = ssl.OPENSSL_VERSION

But I'm not sure we want to change that, the openssl version of the ssl module gives an interesting statistic and the openssl version used to actually download packages would be an other one.

@dstufft
Copy link
Member

dstufft commented Nov 4, 2017

I think we'd want to expose the version of OpenSSL we're actually using to talk to the internet with, although I'm not sure offhand how to do that with cryptography or how to know if requests is going to use ssl or pyopenssl.

@pradyunsg
Copy link
Member Author

I came up with something. Relavent lines that make me think this is what we want to do:

urllib3/util/ssl_.py:14
urllib3/contrib/pyopenssl.py:117
requests/help.py:L76

@pradyunsg pradyunsg dismissed xavfernandez’s stale review November 5, 2017 10:58

There have since been changes made.

@pradyunsg
Copy link
Member Author

pradyunsg commented Nov 7, 2017

https://github.com/pradyunsg/pip/blob/945196e5f0dcf47279d328a6bbdaef11324c2e4d/src/pip/_internal/__init__.py#L23

What do we want to do about these lines?

PS: On MacOS with OpenSSL < 1.0.1, were we posting the wrong version of openssl due to the fact that urllib3 was injected but not actually used?

(edit: rephrased as a question)

@pradyunsg
Copy link
Member Author

pradyunsg commented Nov 8, 2017

What do we want to do about these lines?

🔥 them.

(edit: no dum dum me, they stay)

@pradyunsg pradyunsg requested a review from a team November 8, 2017 15:13
if (sys.platform == "darwin" and
ssl.OPENSSL_VERSION_NUMBER < 0x1000100f): # OpenSSL 1.0.1
try:
from pip._vendor.urllib3.contrib import securetransport
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we removing this? This is needed to support macOS < High Sierra once PyPI is TLSv1.2+.

@alex
Copy link
Member

alex commented Nov 8, 2017

Your most recent commit appears to totally disable SecureTransport -- I don't see any other code which enables it.

Am I misreading?

@pradyunsg
Copy link
Member Author

Whoops. I misread the import. :/

@pradyunsg
Copy link
Member Author

Reverted.

@pradyunsg pradyunsg requested a review from a team November 8, 2017 15:19
@pradyunsg
Copy link
Member Author

Is there anything outstanding on this?

@@ -46,11 +48,22 @@
from pip._internal.utils.ui import DownloadProgressProvider
from pip._internal.vcs import vcs

# We don't try to import OpenSSL on Windows since that might result in it
# loading C libraries, which can then not be uninstalled.
if not WINDOWS:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be a good idea to not duplicate this logic, and instead use the variables that urllib3 sets, see:

https://github.com/shazow/urllib3/blob/master/urllib3/contrib/pyopenssl.py#L109-L118

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

orig_util_SSLContext is never None -- https://github.com/shazow/urllib3/blob/master/urllib3/util/ssl_.py#L90

I do think calling _validate_dependencies_met is a good idea.

@dstufft
Copy link
Member

dstufft commented Mar 16, 2018

Looks OK to me, one comment about duplicating some logic.

@pfmoore
Copy link
Member

pfmoore commented Mar 26, 2018

@pradyunsg Are you planning on merging this? There's a minor review commend from @dstufft to consider.

@pradyunsg
Copy link
Member Author

I am. One minute.

@pradyunsg pradyunsg requested a review from a team March 30, 2018 08:04
@pradyunsg pradyunsg self-assigned this Mar 30, 2018
dstufft
dstufft previously approved these changes Mar 30, 2018
@@ -119,7 +137,10 @@ def user_agent():
data["cpu"] = platform.machine()

if HAS_TLS:
data["openssl_version"] = ssl.OPENSSL_VERSION
if IS_PYOPENSSL:
data["openssl_version"] = OpenSSL.SSL.OPENSSL_VERSION_NUMBER
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong:

>>> import OpenSSL
>>> OpenSSL.SSL.OPENSSL_VERSION_NUMBER
269484175
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2o  27 Mar 2018'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually believe we should roll this back entirely and always send ssl.OPENSSL_VERSION, so the data is consistent. Sending different data in ways that can't be detected in teh database is a bad idea.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, after talking to Alex I think I agree.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there's some way to make a string representation of the version number, would that be fine?

@pradyunsg pradyunsg closed this Mar 30, 2018
@pradyunsg pradyunsg reopened this Mar 30, 2018
@alex
Copy link
Member

alex commented Mar 30, 2018 via email

@pradyunsg
Copy link
Member Author

Awesome. That'll make this PR much lighter.

@pfmoore
Copy link
Member

pfmoore commented Mar 30, 2018

@pradyunsg I assume you'll be merging this soon? I'll be cutting the 10.0 beta in about 12 hours (Saturday morning UK time).

This and the author cleanup (#5118) are basically the last remaining PRs that I'm expecting to go in to 10.0.

@pradyunsg
Copy link
Member Author

pradyunsg commented Mar 30, 2018 via email

@pradyunsg
Copy link
Member Author

pradyunsg commented Mar 30, 2018 via email

@pfmoore
Copy link
Member

pfmoore commented Mar 30, 2018

OK. I'll be offline now until tomorrow morning, so I'll check back on this PR then. We've had an approval; from @alex so once @dstufft approves it, it can go. I can do the merge if you're not around.

@pradyunsg
Copy link
Member Author

pradyunsg commented Mar 30, 2018 via email

@dstufft dstufft merged commit 0007825 into pypa:master Mar 30, 2018
@amp343
Copy link

amp343 commented Mar 31, 2018

👍 @pradyunsg thanks for working this through

@pradyunsg pradyunsg deleted the vendoring/enable-c-libs branch April 1, 2018 07:18
@pradyunsg pradyunsg restored the vendoring/enable-c-libs branch May 27, 2018 09:38
@pradyunsg pradyunsg deleted the vendoring/enable-c-libs branch May 27, 2018 10:08
@lock
Copy link

lock bot commented Jun 2, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation project: vendored dependency Related to a vendored dependency type: enhancement Improvements to functionality type: security Has potential security implications
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SNIMissingWarning / InsecurePlatformWarning not fixable with pip 9.0 / 9.0.1
8 participants