Update certifi version to address critical CVE

Addresses the following:
https://nvd.nist.gov/vuln/detail/CVE-2023-37920

Hi @HarryCaveMan 

This change isn't required. Requests already supports the latest version of cryptography and users are free to upgrade as needed.

We don't intend to change the floor at this time, so we'll close this PR out.

@nateprewitt This change is required to enable automated vulnerability detection to not flag this project as vulnerable if deployed as-is out of the box. I would kindly ask that you reconsider this proposed commit. 

@roalkl Nothing about this change would affect automated detection. You're free to install the latest version of certifi with Requests, raising the floor has no effect on that.

If this is still causing your security scanner to raise a warning, I'd recommend _carefully_ reviewing your dependencies to see if anything else is pinning certifi to an older version. If it is not, you should reach out to your vendor because the detection is incorrect.

Thanks @nateprewitt ! I have been leaning toward the vendor having an opportunity to improve their Python scanning. We did install the latest certifi and the only artifact that appears to tie back is this one. It made no sense as we were superseding with a newer version, however the vendor said to contact here first. Now to convince them that this is the case.

@roalkl We appreciate you helping the vendor correct this issue, it'll help countless other projects too! 🙏

Hello @nateprewitt where in the code of Requests its support for the latest cryptography? I might need it as proof that the vulnerability is resolved

My use case involves using Bazel, and it currently selects an outdated version of Certifi as valid. I'm curious to see what would happen if we let the CI run with the newer version. It might reveal that there are no issues, which could support the possibility of upgrading Certifi. I'm not sure to understand why the minimum version requirement can't be updated.

> My use case involves using Bazel, and it currently selects an outdated version of Certifi as valid.

This is unrelated to Requests from the sound of it.

You can specify the newer version of certifi in the dependency closure, or use `--upgrade`, and all major packaging tools should respect that. Requests users have a wide set of threat models and use cases. Raising version floors are almost always breaking events and raising the floor has no bearing on what users can install. We always support the latest version of certifi at time of release.

Thank you for your input. To ensure you are making the best decision for the users, could we consider running the CI pipeline to validate your statement ("almost always breaking events")?

Given the high severity of CVE-2023-37920, it seems prudent to encourage the use of the latest secure version of the package. This would help maintain the security and integrity of the project. I guess it is always a trade-off between convenience and security.


@pablospe to be super clear, users will always install the latest version of `certifi` when installing Requests _unless_ they either:

1. Have an old version of `certifi` installed in a reused/unmanaged installation space (we would not recommend this and neither does the official Python Packaging guidance).
2. Have pinned, or have a dependency that pins, to an older version of `certifi`. The pin can be updated by either you or your dependency when you've evaluated the change. This proposed PR will break every user/system in this group without recourse.

> could we consider running the CI pipeline to validate your statement ("almost always breaking events")?

I think you've misunderstood my statement. Our CI will not break, anyone relying on older versions of certifi (or packages that are still pinned to older versions) will break. We cannot test the millions of systems using Requests from a single GitHub Action workflow.

Requests takes packaging security very seriously, but security is a shared ownership model. We will typically not push unnecessary breakages to facilitate users who are not compliant with basic packaging/dependency management practices.

Thanks a lot for the clear explanations!