[CVE Remediation] Upgrade urllib3 to 2.8.0 or greater.

[mjohanse-emr]

What does this Pull Request accomplish?

Update all packages to explicitly require urllib3>=2.8.0. This is a transitive dependency we get through various sphinx packages.

I added <3.0 as a conservative compatibility bound, matching requests existing constraint (urllib3 >=1.26,<3)

Why should this Pull Request be merged?

AB#4105421

We want to upgrade urllib3 to address vulnerabilities.

What testing has been done?

PR checks (documentation builds)

[github-actions]

Test Results

  120 files  ±0    120 suites  ±0   3m 19s ⏱️ -11s
  444 tests ±0    432 ✅ ±0   12 💤 ±0  0 ❌ ±0 
4 440 runs  ±0  4 286 ✅ ±0  154 💤 ±0  0 ❌ ±0 

Results for commit 419f8a5. ± Comparison against base commit c1334a6.

[bkeryan]

Adding this dependency to each project is unnecessary. To upgrade indirect dependencies, use Renovate to do "lock file maintenance".

[mjohanse-emr]

@bkeryan
I think I may be misunderstanding how CVE remediation is supposed to work for python packages. I know that dependabot uses the .lock file to determine if there is an issue, but other than that, the .lock file doesn't affect what is installed to the client's machine using pip install. Therefore, I thought it would be necessary to update our pyproject.toml to ensure that we are shipping at least 2.8.0, regardless of what is in the lock file.

If we don't update the pyproject.toml, can we rely on pip install to resolve to urllib3>=2.8.0?

[bkeryan]

the .lock file doesn't affect what is installed to the client's machine using pip install.

Right. The lock file affects what is installed when running CI/PR workflows.

Therefore, I thought it would be necessary to update our pyproject.toml to ensure that we are shipping at least 2.8.0, regardless of what is in the lock file.

We are not "shipping" urllib3.

We are not referencing urllib3 in our distribution package's metadata.

To see the package metadata, unzip the .whl file (e.g. https://files.pythonhosted.org/packages/53/ee/c2f7ce4b004422addd6e02eef69a2606b26966da56098a8d1667a64cba20/ni_grpc_extensions-1.1.0-py3-none-any.whl) with 7-Zip and look at the file in the dist-info directory called METADATA:

Metadata-Version: 2.3
Name: ni-grpc-extensions
Version: 1.1.0
Summary: gRPC Extensions
License: MIT
Keywords: grpc,extensions,channel_pool
Author: NI
Author-email: opensource@ni.com
Maintainer: Joe Friedrichsen
Maintainer-email: joe.friedrichsen@emerson.com
Requires-Python: >=3.10,<4.0
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Manufacturing
Classifier: Intended Audience :: Science/Research
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: Microsoft :: Windows
Classifier: Operating System :: POSIX
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: 3.14
Classifier: Programming Language :: Python :: Implementation :: CPython
Requires-Dist: grpcio (>=1.49.0,<2.0)
Requires-Dist: traceloggingdynamic (>=1.0) ; sys_platform == "win32"
Project-URL: Documentation, https://ni-grpc-extensions.readthedocs.io/en/latest/
Project-URL: Repository, https://github.com/ni/ni-apis-python
Description-Content-Type: text/markdown

These are all of the dependencies:

Requires-Dist: grpcio (>=1.49.0,<2.0)
Requires-Dist: traceloggingdynamic (>=1.0) ; sys_platform == "win32"

If we don't update the pyproject.toml, can we rely on pip install to resolve to urllib3>=2.8.0?

Our distribution packages do not depend on urllib3, do they? The "docs" dependency group indirectly depends on urllib3, but we don't ship the "docs", "test", "lint", etc. dependency groups in the distribution package.

[mjohanse-emr]

I'll trigger renovate to perform this update on the lock files. This change isn't necessary anymore.