`safety` requires `crypography>=39.0.0` which hasn't been released yet

[figchutney]

• safety version: 1.10.3
• Python version: 3.10.2
• Operating System: MacOS 11.7

Description

Hello 👋

safety currently requires cryptography>=39.0.0 for its checks to pass (see screenshot), citing the below reason, with ID 51159:

Cryptography 39.0.0 drops support for C library "LibreSSL" < 3.4, as these versions are not receiving security support anymore.

However, it looks like version 39.0.0 of cryptography is under development and hasn't been released yet.

As far as I can see, the only way around this for now is to ask safety to ignore its check on cryptography.

There's a comment on commit https://github.com/pyupio/safety-db/commit/e582a03665fde14b58dd247b5d33aa4c0f0832e5 about it here.

Thanks 🙏

What I Did

Ran the following:

safety check --full-report --file=requirements.txt

[alex]

Hi, I'm one of the pyca/cryptography primary maintainers.

This isn't a security issue in pyca/cryptography in the first instance. It's removing support for interoperating with older LibresSSL versions. To a certain extent using old unsupported libressl is a security issue, but that's fixed by upgrading libressl, not by upgrading cryptography.

I'd strongly encourage the safety maintainers to consult with the pyca/cryptography maintainers when creating vulnerability reports for us. We always request CVEs when fixing vulnerabilities.

[yeisonvargasf]

Hi @figchutney and @alex, thanks for reporting this, and let me explain:

Safety identified that minor versions than 39.0.0 support the C library "LibreSSL" < 3.4, vulnerable to CVE-2021-41581.

This vulnerability is transitive, so it doesn't mean that pyca/cryptography has the vulnerability itself; this probably is a misunderstanding because many users are using an old Safety version where the Transitive isn't handled similarly. In newer versions of Safety, transitive vulnerabilities are reported only when the scan isn't an environment scan. Also, the JSON report will show that it is a transitive vulnerability.

In new versions of Safety, you will be able to find a URL with more info about the vulnerability, https://pyup.io/vulnerabilities/CVE-2021-41581/51159/ and also you can ignore the vulnerability with a reason

For Safety users:

When you see a transitive, you need to evaluate and assess if that transitive vulnerability affects you immediately and make the proper decision. For this specific case, we recommend verifying the "LibreSSL" version, upgrading if you are vulnerable, and ignoring with a reason and expiring the pyca/cryptography vulnerability, so you can upgrade later when 39.0.0 is released.

This isn't a security issue in pyca/cryptography in the first instance. It's removing support for interoperating with older LibresSSL versions. To a certain extent using old unsupported libressl is a security issue, but that's fixed by upgrading libressl, not by upgrading cryptography.

@alex, this is true, we agree, but upgrading pyca/cryptography forces companies to stay on the safe side, as they won't have a version compatible with those older LibreSSL versions. Safety is looking always to stay on the safe side.

I'd strongly encourage the safety maintainers to consult with the pyca/cryptography maintainers when creating vulnerability reports for us. We always request CVEs when fixing vulnerabilities.

@alex, I'll consult with the Security Team about this; I think they didn't get in touch because it is a transitive vulnerability. Also, I think this is probably a misunderstood about how Safety transitive works, and I'll ask the team for more documentation on this topic.

Thank you both! Let me know if you have questions or proposals, from my side I think we will need more documentation related to transitives in Safety, also we are working on improvements to the transitive verification in environment scans.

[alex]

This is a very confusing way of handling transitive vulnerabilities. pyca/cryptography does not ship with LibreSSL in any form. Using a cryptography<39 does not mean you're using LibreSSL<3.4, in fact almost no cryptography users do (except those on OpenBSD).

[reaperhulk]

(I am another pyca/cryptography developer) It appears that this was added as a vulnerability due to a future backwards incompatible version drop we have chosen to do in pyca/cryptography. The outcome of this has been multiple issues filed as well as mailing list traffic asking us when we’re going to remediate an issue that is not an issue.

We very much like having people upgrade to the latest version, but this both asks users to upgrade to a version we do not have a release date for and assumes the use of a library (LibreSSL) which almost nobody actually consumes.

[yeisonvargasf]

Hi everyone. For now, we have decided to remove the vulnerability and update our databases to reflect this. Even though this vulnerability is valid for a subset of users, given that the maintainers report that the vast majority of users are unaffected we can remove it for now. Thanks for bringing this up, and for everyone’s patience. Our security team will look at this again soon; if we consider it worth publishing, we will first contact maintainers to discuss it before sending it to the public. (I'm closing this thread too)

[figchutney]

Thanks everyone 👌🙏