Cannot import appengine

[firaskafri]

How do you use Sentry?

Sentry Saas (sentry.io)

Version

1.18.0

Steps to Reproduce

Install the SDK within any project that is not pinning urllib3 < 2.0.0

Expected Result

ability to import appengine

Actual Result

Cannot import appengine as gaecontrib.
As per urllib 2.0.0 release: https://github.com/urllib3/urllib3/tree/2.0.0

Removed urllib3.contrib.appengine.AppEngineManager and support for Google App Engine Standard Environment (urllib3/urllib3#2044).

[antonpirker]

Hey @firaskafri !

Thanks for reporting this. Can you post the error with stacktrace you get in your project when you try to import appengine?

[mattiamatrix]

sentry-sdk should probably support urllib3 2.0.0 psf/requests#6432 or fix the dependencies

[pquentin]

Hello! As one of the urllib3 maintainers, I'd be happy to help, but so far we have no idea what the issue is, which is why an actual error with a traceback would be nice, as it would help understand where the issue is. (I don't think sentry-python imports urllib3.contrib.appengine itself?)

[mattiamatrix]

Thanks @pquentin, I came here because in AWS Lamdba I got:

[ERROR] Runtime.ImportModuleError: Unable to import module 'step_function_trigger': urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with OpenSSL 1.0.2k-fips  26 Jan 2017. See: https://github.com/urllib3/urllib3/issues/2168
Traceback (most recent call last):

It might or might not be related. But I notice that the link in the error is sending directly to you ;)

[pquentin]

Thanks! Note that this is different from the App Engine issue above. (And it has nothing to do with sentry-python.) It is a known issue with Amazon Linux 2 (the default AWS Lambda distribution) that is using OpenSSL 1.0.2, a version that has not been supported by the OpenSSL project for 3+ years now. My understanding is that Amazon Linux 2 is applying RHEL 7 patches to keep this version secure.

Anyway, I believe you have the following options:

1. Pin urllib3 to <2.0 (we will continue supporting 1.26.x for now)
2. Upgrade to Python 3.9 or above, where AWS Lambda runtimes come with OpenSSL 1.1.1
3. Switch to a custom Docker image with OpenSSL 1.1.1+ support

[pquentin]

urllib3 contributor @illia-v was surprised by the above statement, since Python 3.10 requires OpenSSL 1.1.1. They kindly checked the OpenSSL versions in AWS Lambda, with the following results:

• Python 3.9 and 3.10 – OpenSSL 1.1.1t 7 Feb 2023
• Python 3.7 and 3.8 – OpenSSL 1.0.2k-fips 26 Jan 2017

Good news! The best fix here is actually to upgrade your runtime to Python 3.9+. I've edited my comment above.

[sl0thentr0py]

hey I'm gonna pin to < 2.0.0 for now, and investigate if we need any other changes separately and also wait for the ecosystem to stabilize

[mattiamatrix]

@pquentin with 3.9 and 3.10 I still get

cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_' (/var/task/urllib3/util/ssl_.py)

The simplest solution is indeed urllib3<2.0.0

[pquentin]

@mattiamatrix This is a different issue though: botocore (and by extension boto3) does not support urllib3 2.0 yet: boto/botocore#2926. Make sure to use a recent enough pip when installing your dependencies! botocore pins urllib3<1.27 so you should never have seen urllib3 2.0 in the first place.

But at least if you're using 3.9 or 3.10 you'll be ready when boto3 starts supporting urllib3 2.0. I would recommend this long read on the best approach to handle Python dependencies: https://hynek.me/articles/semver-will-not-save-you/

[mattiamatrix]

Thank you @pquentin, you are great!

[pquentin]

I'm starting to see users that cannot use urllib3 2.0 because they use sentry-sdk: uktrade/enquiry-mgmt-tool#589. Unless there's an actual compatibility issue, I don't think pinning to urllib3<2 should be your decision. https://hynek.me/articles/semver-will-not-save-you/ explains it well, here's the relevant excerpt.

But Wait – It Gets Worse!

If you maintain a public package and pin the major version of a dependency of yours, you transitively do this to the applications of your users.

Imagine an application depends on the wonderful urllib3 and your package does too. Now if you pin urllib3 to <2, the user of your package doesn’t have it in their power to ever receive an update from urllib3 again, once urllib3 bumps its major version to 2 and beyond. They may not even realize how far back they are.

On the other hand, if a new major version of a package surprisingly breaks your package, they can always add a pin themselves (see step 4 above) until you fix your package. But there’s no practical way for them to remove your pin.

Don’t ever pin major versions, unless you know they’re broken.

Some Python packaging tools have adopted npm’s major-version pinning (^) by default, despite the lack of npm’s security features and despite Python’s flat package space. Make sure to unpin them by hand if possible.

(And, yes, this was written before urllib3 released 2.0., but this is no longer hypothetical now.)