If a library package supports a wide range of Python versions, there are cases where a vulnerability reported by safety can be fixed only for a subset of the supported Python versions. In that case, the requirements file of the package typically contains PEP 496 markers to distinguish the different versions by some condition, most notably the Python version, e.g.:
Assuming that xyz 2.0 fixes vulnerability 12345 but requires Python>=3.6, then the package owner can be as willing as they want, but they cannot get that fixed completely (other than abandoning support for the old Python version which may not be possible).
In such a case, the user with today's safety functionality needs to specify the vulnerability to be ignored even though it was partly addressed. That lets the safety report look worse than it actually is.
I propose to add support for PEP 496 environment markers that allow specifying a condition under which the vulnerability is ignored. That would be used to specify the condition where the issue could not be fixed for some reason. In the example above, the policy file might specify that as:
Description
If a library package supports a wide range of Python versions, there are cases where a vulnerability reported by safety can be fixed only for a subset of the supported Python versions. In that case, the requirements file of the package typically contains PEP 496 markers to distinguish the different versions by some condition, most notably the Python version, e.g.:
Assuming that xyz 2.0 fixes vulnerability 12345 but requires Python>=3.6, then the package owner can be as willing as they want, but they cannot get that fixed completely (other than abandoning support for the old Python version which may not be possible).
In such a case, the user with today's safety functionality needs to specify the vulnerability to be ignored even though it was partly addressed. That lets the safety report look worse than it actually is.
I propose to add support for PEP 496 environment markers that allow specifying a condition under which the vulnerability is ignored. That would be used to specify the condition where the issue could not be fixed for some reason. In the example above, the policy file might specify that as:
The condition should also be surfaced in the report.