Strange security vulnerability 41002

[sobolevn]

Today all my builds (like literally all of them) failed, because coverage is reported to be insecure.
Full message:

 + safety check --full-report
+==============================================================================+
|                                                                              |
|                               /$$$$$$            /$$                         |
|                              /$$__  $$          | $$                         |
|           /$$$$$$$  /$$$$$$ | $$  \__//$$$$$$  /$$$$$$   /$$   /$$           |
|          /$$_____/ |____  $$| $$$$   /$$__  $$|_  $$_/  | $$  | $$           |
|         |  $$$$$$   /$$$$$$$| $$_/  | $$$$$$$$  | $$    | $$  | $$           |
|          \____  $$ /$$__  $$| $$    | $$_____/  | $$ /$$| $$  | $$           |
|          /$$$$$$$/|  $$$$$$$| $$    |  $$$$$$$  |  $$$$/|  $$$$$$$           |
|         |_______/  \_______/|__/     \_______/   \___/   \____  $$           |
|                                                          /$$  | $$           |
|                                                         |  $$$$$$/           |
|  by pyup.io                                              \______/            |
|                                                                              |
+==============================================================================+
| REPORT                                                                       |
| checked 156 packages, using free DB (updated once a month)                   |
+============================+===========+==========================+==========+
| package                    | installed | affected                 | ID       |
+============================+===========+==========================+==========+
| coverage                   | 5.5       | <6.0b1                   | 41002    |
+==============================================================================+
| Coverage 6.0b1 starts to use a modern hash algorithm (sha256) when           |
| fingerprinting for high-security environments.                               |
+==============================================================================+

Full logs example: https://github.com/wemake-services/wemake-django-template/pull/1667/checks?check_run_id=3216651270#step:7:1364

Why do I think that this is a strange security report?

1. coverage is my dev tool, it don't think that this is an attack vector
2. It is not clear how a hash algorithm can be a problem for calculating coverage while running tests on a trusted env
3. It suggests to install a beta release, which is not the best practice at all

I might be wrong here, it might be a real problem, which is just not clear to me from the first sight.

Proposed solution

I see that I can report a security issue via Tidelift, but I don't see a security policy in the project.
Something like https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
Maybe it should be created? This way all huge user-base of your awesome project could benefit from understanding what is a security issue with coveragepy and what's not.

Related, npm has similar problems described here: https://overreacted.io/npm-audit-broken-by-design/

[nedbat]

Version 6.0b1 has already fixed this. The safety report you have even mentions the sentence from the changelog about it. It was reported in #1189.

[bluenote10]

Since 6.0b1 is a beta release, pip doesn't use it by default. Would it make sense to a release a non-beta version? Technically there is currently no stable published version of coverage that passes the Safety scan.

[whyscream]

When reading #1189, it's not obvious to me that this is a security vulnerability, but rather a serious inconvenience/bug under some security-related circumstances. That would IMHO result in an incorrect listing in the safety database for this issue. @nedbat Could you shed some light at this?

[sobolevn]

@nedbat sorry, I think that I was not clear enough with my initial issue report.

Version 6.0b1 has already fixed this.

Version 6.0b1 fixes the #1189 bug, but my point is about coveragepy's security policy.

[nedbat]

@whyscream Right: this is not a security issue. It's a security scanner flagging any mention of md5. Coverage.py used md5 simply to fingerprint HTML files. There was no security concern. But it was easy to change to avoid these kinds of false alarms.

[whyscream]

@nedbat thanks, I created an issue for safety-db to remove the listing: pyupio/safety-db#2335. Let's see how that works out.