Project

Profile

Help

Issue #9367

closed

pulpcore 3.15 depends on cryptography 3.4.z, which is not available on EL7

Added by evgeni about 1 year ago. Updated 11 months ago.

Status:
CLOSED - DUPLICATE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
Estimated time:
Severity:
3. High
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Ticket moved to GitHub: "pulp/pulpcore/2043":https://github.com/pulp/pulpcore/issues/2043


Ohai,

in https://github.com/pulp/pulpcore/commit/387995199e19f087e4ee6996128744ee7fc94dd5 a dependency on cryptography~=3.4.7 was added (later bumped to 3.4.8 by a bot).

However, cryptography 3.3+ can't be built against OpenSSL 1.0 anymore, but there is no OpenSSL 1.1 in EL7.

Additionally, while cryptography 3.2 can be built against OpenSSL 1.0, it needs consumers to export CRYPTOGRAPHY_ALLOW_OPENSSL_102=1 in their environment, as otherwise cryptography fails to load.

Can you please relax the requirement, so that we can ship an older cryptography (right now we're on 2.9.2, cough) at least on EL7.

Actions #1

Updated by daviddavis about 1 year ago

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.

Actions #2

Updated by dalley about 1 year ago

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?

Actions #3

Updated by evgeni about 1 year ago

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 ;)

Actions #4

Updated by daviddavis about 1 year ago

@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)?

Actions #5

Updated by evgeni about 1 year ago

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

Actions #6

Updated by dkliban@redhat.com about 1 year ago

  • Triaged changed from No to Yes
Actions #7

Updated by pulpbot 11 months ago

  • Description updated (diff)
  • Status changed from NEW to CLOSED - DUPLICATE

Also available in: Atom PDF