Page MenuHomePhabricator

Wmfdata's fails with Urllib3 v2 or higher
Closed, ResolvedPublic



Wmfdata users can work around this by running conda install "urllib3 < 2".

Detailed description

Wmfdata's uses the Prestodb package, which depends on Requests, which in turn depends on Urllib3.

an-coord1001's TLS certificate does not have the host name in the subjectAltName field (T158757). As a result, Urllib3 before v2 throws a warning when connecting to it, before falling back to the commonName field. We disabled the warning with the following code:

SubjectAltNameWarning = urllib3.exceptions.SubjectAltNameWarning

However, in Urllib3 v2, the behavior of falling back to the commonName is removed (along with the associated warning object).

As a result, with Urllib3 v2:

  • if the warning suppression code is in place, importing Wmfdata fails (P52118)
  • if the warning suppression code is removed, fails with a TLS error (P52119)

Possible solutions

Urllib3 v2 still allows us to restore the previous behavior using the option SSLContext.hostname_checks_common_name = True. However, we don't have direct access to this since we're so many layers removed from Urllib3. It might be possible to set this by taking our initialized Prestodb Connection objection and modifying its _http_session property, which is a Requests Session object. That object may provide some access to the underlying Urllib3 SSLContext (I haven't researched it). However, even if it works, accessing private variables this ways seems dubious.

Otherwise, the best short-term solution is pinning Urllib3 below v2, and the best long-term solution is fixing T158757 (which will have broad benefits since there are plenty of other uses of Urllib3 in our infrastructure).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
nshahquinn-wmf closed this task as Resolved.EditedSep 1 2023, 5:34 PM
nshahquinn-wmf claimed this task.

Wmfdata now pins Urllib3 below v2 (PR 45), so that's the short-term solution done.

Apparently, the underlying problem with our key certificates (T158757) will get fixed as our infrastructure is upgraded to Puppet 7 (T330490), so the long-term solution is in progress.