Package coverage<6.0b1 incorrectly listed as vulnerable

[whyscream]

As discussed in nedbat/coveragepy#1198 with the author of the coverage package. The former usage of the md5 algorithm in coverage is not a security vulnerability. The listing in safety-db forces (or rather tries to convince) lots of people to upgrade to a newer version that is both beta and a major upgrade, for no good reason (security-wise).

Would you consider removing the entry for coverage<6.0b1 from the database?

[nedbat]

I'm interested to know more about how entries get created in this database in the first place. You seem to have used words from my CHANGELOG, so there's a human making the entries. If you notify the owner of the repo, then we could short-circuit some of the churn around entries like this that are more alarming than they need to be.

[yeisonvargasf]

Hi @whyscream, thanks for reporting this issue. We reviewed in detail and this was a false positive, we have marked the vulnerability as INVALID and the update will be available soon.

@nedbat we usually notify repo owners to clarify the possible vulnerability, this time MD5 was a red flag (even FIPS blocks it regardless of context) for our security team while doing the verification (about your question, there is a security team checking each possible vulnerability). We will reach you if the security team has questions about a possible vulnerability.

[nedbat]

It's just a little disappointing that my change was specifically to silence a false alarm that had been reported, and my change caused you to create another false alarm. :(

[awsbillz]

Hi @whyscream, thanks for reporting this issue. We reviewed in detail and this was a false positive, we have marked the vulnerability as INVALID and the update will be available soon.

@nedbat we usually notify repo owners to clarify the possible vulnerability, this time MD5 was a red flag (even FIPS blocks it regardless of context) for our security team while doing the verification (about your question, there is a security team checking each possible vulnerability). We will reach you if the security team has questions about a possible vulnerability.

Do we have an ETA on when this false alarm will be fixed by updates?

[yeisonvargasf]

Hi @nedbat I know what you mean, sorry for that, I think a more detailed clarification in changelogs will help to don't produce false positives in the future and our team probably will reach you next time if a security item in the changelog isn't clear for them.

@awsbillz the correction was done after this issue was reported, it will show up for our paid users immediately and not until September 1st for our users without a paid subscription.

We can review/accept any PR in an expedited way if you want to remove the false positive before that date. You will have to remove the vulnerability from: insecure.json and insecure_full.json

[sobolevn]

@yeisonvargasf done: #2337