CVE's

[mcandre]

The Snyk CLI reports vulnerabilities on the PyPI safety package.

https://snyk.io/

$ cat requirements.txt
safety

$ snyk test

Testing /Users/andrew...

Tested 13 dependencies for known issues, found 1 issue, 1 vulnerable path.


Issues to fix by upgrading dependencies:

  Pin [email protected] to [email protected] to fix
  ✗ Resource Exhaustion (new) [Medium Severity][https://security.snyk.io/vuln/SNYK-PYTHON-IDNA-6597975] in [email protected]
    introduced by [email protected] > [email protected] > [email protected]



Organization:      mcandre
Package manager:   pip
Target file:       requirements.txt
Project name:      andrew
Open source:       no
Project path:      /Users/andrew
Licenses:          enabled

Tip: Try `snyk fix` to address these issues.`snyk fix` is a new CLI command in that aims to automatically apply the recommended updates for supported ecosystems.
See documentation on how to enable this beta feature: https://docs.snyk.io/snyk-cli/fix-vulnerabilities-from-the-cli/automatic-remediation-with-snyk-fix#enabling-snyk-fix

By the way, the requests library may be overkill. It's just a wrapper. One way to resolve the vulnerability is to drop that dependency and use the standard library directly.

[yeisonvargasf]

Thanks, @mcandre, for this report.

As a solution, you can pin idna, and yes, we will drop requests in a future minor release.

Safety makes the best effort to avoid pinning dependencies and prevent compatibility issues. Nevertheless, we will look to integrate suggested minimum constraints for dependencies or document them for users who want to enforce them.

[mcandre]

Hi, it's been a month.

When can we expect this security enhancement to be released?

[mcandre]

Hi,

It's been months since this vulnerability was reported. When can expect safety to resolve this vulnerability?

[dylanpulver]

Hi @mcandre,

Thank you for your patience and for bringing this issue to our attention.

After consideration, we've decided to move this issue to the "wontfix" category. We wanted to provide some context for this decision:

1. Pinning Dependencies: While we understand the value of pinning idna to address the vulnerability, we aim to maintain flexibility and compatibility across different environments. Pinning could lead to compatibility issues for other users.
2. Dropping requests Dependency: We recognize that using the standard library could be a simpler solution, but removing the requests dependency involves significant changes to our codebase and isn't part of our immediate development plans.
3. Alternative Solutions: Users can mitigate this issue by manually pinning the idna dependency in their projects if needed.

We deeply value security and will continue to monitor and address vulnerabilities in future updates. For this particular issue, we believe the proposed fixes would be challenging to implement without affecting our broader user base.

Thank you for your understanding and for your continued contributions to the project. If you have any further suggestions or reports, we'd love to hear from you!

Best Regards, The Safety Team

[mcandre]

Yuck.