# Notes from discussion RE failing https: ## 2024-06-11 mdellweg/ggainey * feels like upgrading requests from 2.31.X to 2.32 (happened 4 days ago) * https://github.com/pulp/pulp-cli/pull/981 * Failures: * pulp-replication talking to the pulp-instance, from pulp-glue, fails * talking to django-azure form the pulp-instance, using https, fails * the bindings (which run "inside" the same container as the pulp-instance), use https, and WORK * Findings: * requests lib usage in pulp updated 4 days ago to allow 2.32.x * we picked it up to pick up a CVE * https://github.com/psf/requests/security/advisories/GHSA-9wx4-h78v-vm56 * 2.32 changes involve a lot of SSLContext notes * https://github.com/psf/requests/blob/main/HISTORY.md * there have already been regressions in that stream * e.g. https://github.com/psf/requests/pull/6724 * 2.32.0 and 2.32.1 were yanked for incompatibility issues * 2.32.3 has another regression opened against it * https://github.com/psf/requests/issues/6730 * https://github.com/psf/requests/pull/6731 * Decisions: * we don't need to use https to talk to azure * we don't use it for S3 * using it adds a bunch of infrastructure-management/openssl overhead to that set of tests * it doesn't test pulp-code - it tests (at best) django-storage-azure, and at worst "the ability of the Pulp CI Team to get self-signed certs into the right magic locations" * https://github.com/pulp/plugin_template/pull/875 * let's try disallowing 2.32.3 *and* using http on azure * https://github.com/pulp/pulpcore/pull/5466 * still failing on replication :( * Requiring requests<2.32 makes the problem go away * so it is *definitely* the 2.32 release that broke us * can pulp-glue be affected by the CVE? * I am pretty sure no. We basically follow the second option to mitigate outlined in the CVE. "Do not use verify=False on a request from a session with verify=True". We only ever specify verify once on the session. * if it can be - can we use the workaround noted in the CVE-report to fix that, so we can stay on 2.31? * alternatively, we can try working around the 2.32 regression by always pointing to a ca store. * will requests fix the regression? * What else can they do? Call it a feature? * stay tuned!