Bug 2009550

Summary: "DeprecationWarning: ssl.match_hostname() is deprecated" on Fedora 35 / Rawhide (Python 3.10)
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: python-urllib3Assignee: Fedora Infrastructure SIG <infra-sig>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 35CC: aurelien, infra-sig, jeremy, mhroncok, orion, python-sig, TicoTimo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: python-urllib3-1.26.7-2.fc35 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-08 01:19:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2036692    

Description Adam Williamson 2021-09-30 23:00:37 UTC
Doing just about anything in anything that uses urllib3 (which is a ton of things) causes this DeprecationWarning:

/usr/lib/python3.10/site-packages/urllib3/connection.py:512: DeprecationWarning: ssl.match_hostname() is deprecated
  match_hostname(cert, asserted_hostname)

I tested with 1.26.7 (just released), but it still has the issue. There's also another deprecation warning I see in some cases:

    /usr/lib/python3.10/site-packages/urllib3/util/retry.py:38: DeprecationWarning: Using 'Retry.DEFAULT_METHOD_WHITELIST' is deprecated and will be removed in v2.0. Use 'Retry.DEFAULT_ALLOWED_METHODS' instead

I added a comment to an upstream issue on this - https://github.com/urllib3/urllib3/issues/2200#issuecomment-931759912 .

Comment 1 Adam Williamson 2021-09-30 23:01:50 UTC
oh, that second one is probably a deprecation warning in the app I'm running, ignore that. But the other one is in urllib3 itself.

Comment 2 Miro Hrončok 2021-10-01 18:05:56 UTC
Note that the upstream's response indicates they will resolve this by bundling.

Comment 3 Adam Williamson 2021-10-01 18:45:52 UTC
well, sorta, but then the commit from the main branch that they reference - https://github.com/urllib3/urllib3/pull/2198/files - doesn't seem to do that, exactly. or if it does, it just moved it from one place where it already was (`_implementation.py`), to another. I had actually run across that commit already in looking into this issue, but wasn't entirely clear on exactly what was going on there.

Comment 4 Miro Hrončok 2021-10-01 21:34:38 UTC
We currently remove urllib3/packages/ssl_match_hostname/_implementation.py in %install.

Comment 5 Adam Williamson 2021-10-12 21:30:30 UTC
so upstream has resolved this now:

https://github.com/urllib3/urllib3/pull/2448

Miro, do you think we can just backport this, or what else would you prefer to do?

Comment 6 Miro Hrončok 2021-10-12 22:55:23 UTC
If we are OK with the idea of bundling, I'd do so, yes.

Comment 7 Miro Hrončok 2021-10-12 23:22:47 UTC
Looking into it more, this is clearly a piece of code that Python upstream no longer wishes to maintain and urrlib3 upstream does. Hence, I think forcibly unbundling it would be the wrong thing to do.

We just need to update the license from plain MIT to MIT and Python.

Comment 8 Adam Williamson 2021-10-13 06:02:19 UTC
yeah, that was my take too, the deprecationwarning is literally Python telling us they don't want us to use it any more.

Comment 9 Adam Williamson 2022-01-04 18:17:44 UTC
So, uh, I came back to this today, and I think all that work we got upstream to do was unnecessary. Upstream was already set to vendor it on Python 3.10+. All we had to do was stop explicitly unbundling it downstream. Oh well, let's not tell them. :D

I'm sending a build that drops our unbundling stuff, but doesn't backport the upstream PR as it doesn't apply immediately and doesn't seem to be necessary. Just removing the unbundling makes the deprecation warnings go away in my tests.

Comment 10 Fedora Update System 2022-01-04 18:50:00 UTC
FEDORA-2022-104704f78a has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-104704f78a

Comment 11 Fedora Update System 2022-01-05 01:15:12 UTC
FEDORA-2022-104704f78a has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-104704f78a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-104704f78a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2022-01-08 01:19:26 UTC
FEDORA-2022-104704f78a has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.