Pulp

I looked into supporting older versions. Here's the python cryptography changelog for anyone that also wants to check: https://cryptography.io/en/latest/changelog/

The one thing that stood out to me was the 3.3.2 release fixes a buffer overflow CVE. There's a related openssl CVE too but basically cryptography introduced a workaround to protect users from hitting the openssl security vulnerability.

I've confirmed that our code does hit the update() method that the CVE calls out and we also are dealing with payloads bigger than 2GB (we encrypt textfields that can exceed 2GB in size). So I think that rolling back to cryptography <3.3.2 could expose Pulp users to this security vulnerability.

So I think that rolling back to cryptography <3.3.2 could expose Pulp users to this security vulnerability.

I kind of agree about the upstream packages.

For the RPM builds though, I think we can rely on OpenSSL being updated appropriately. How difficult would it be to carry a patch for this one requirement?

So I think that rolling back to cryptography <3.3.2 could expose Pulp users to this security vulnerability.

You wouldn't be rolling back. New installs would still get the latest (allowed) cryptography if you define the dep like >= 3.0 or something. Or even drop the version requirement alltogether. You just wouldn't force users to that newer, fixed version.

And yeah, I can trivially patch out that version requirement on RPM build, just wanted to make sure with y'all that this is something semi-sensible to do ;)

@evgeni, I noticed that the openssl version in el7 is openssl-1.0.2k-19.el7.x86_64.rpm. I believe this will expose users to https://nvd.nist.gov/vuln/detail/CVE-2021-23840 if we use a cryptography version older than 3.3.2 (see CVE-2020-36242)?

Yeah, this is unpatched in EL7 today, but I would totally think that it will get patched soon.