Recent update causes latest Rust time crate to report old vuln

[jayvdb]

I encountered this wrt https://github.com/github/advisory-database/blame/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json , because time is a very common Rust crate.

Suddenly over the weekend, the latest version of the crate started having vulns reported by it on api.osv.dev.

i.e. curl -d '{"version": "0.3.20", "package": {"name": "time", "ecosystem": "crates.io"}}' "https://api.osv.dev/v1/query"

https://osv.dev/vulnerability/GHSA-wcg3-cvx6-7396 shows the results in a web format.

b010a65 seems to be the cause.

I see it is removing many last_affected, but in the case of time GHSA-wcg3-cvx6-7396, it is only adding an empty "fixed".

The JSON contains

"database_specific": {
        "last_known_affected_version_range": "< 0.2"
}

This feels a bit like #470.
This record should have a last_affected of 0.2.22 according to https://github.com/time-rs/time/blob/v0.2.23/CHANGELOG.md#compatibility-notes , or maybe fixed in 0.2.23.

[KateCatlin]

Hey @jayvdb we should have that fixed for you! Thanks for letting us know.

Do you want to test it on your end and confirm before I close this issue?

[jayvdb]

The solution was to delete "GHSA-wcg3-cvx6-7396"?

I've tested with osv-scanner, and it is still reporting the vuln GHSA-wcg3-cvx6-7396, probably because https://github.com/google/osv.dev hasnt been updated yet. Note, mostly to self, that https://osv.dev/vulnerability/GHSA-wcg3-cvx6-7396 may not show this deletion due to google/osv.dev#1102

[jayvdb]

99dbb63 did updates to fix the last_affected for most records, but deleted GHSA-wcg3-cvx6-7396 without explanation in the commit.

Interesting that GHSA-wcg3-cvx6-7396 still exists, and doesnt yet reflect that it was modified an hour ago.

[chrisbloom7]

The solution was to delete "GHSA-wcg3-cvx6-7396"?

🤔 yeah, was not expecting that when we resynched the data. The rest of the advisories from that batch reverted properly. I'll try synching GHSA-wcg3-cvx6-7396 again. Apologies about the data issues here. We're doing some cleanup of the code that handles converting advisories to OSV JSON files and discovered a regression yesterday.

[chrisbloom7]

@jayvdb good news, bad news. I was able to confirm that the bug you initially reported (fixed versions showing up blank and last_affected getting moved to database specific meta data) was indeed fixed like we thought it was. But, there's another bug that's totally unrelated that's causing GHSA-wcg3-cvx6-7396 to be unprocessable leading to it being deleted. I'm working on that now but may not have it resolved until tomorrow.

[jayvdb]

No worries @chrisbloom7 . osv-scanner has ability to ignore vulns, and we've already used it for this problem. Keen to remove the ignore rule, but another day or two wont hurt.

I am a bit surprised there are not more people "here" somehow making their voice heard about this, given there are 2000 at https://crates.io/crates/time/reverse_dependencies (that '2000' seems suspect - very round, maybe the list is trimmed) - this issue should be effecting almost every Rust program that does anything interesting.

Are Rust devs not using osv-scanner or GHSA via other means? Or do they all have GHSA-wcg3-cvx6-7396 in their ignore lists already and this didnt notice this recent regression? (If anyone else is effected by this, please 👍 the issue; don't comment unless you've something useful to add.)

[chrisbloom7]

@jayvdb https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json has been restored

[jayvdb]

@chrisbloom7 , thanks for bringing it back as https://github.com/github/advisory-database/blob/da022ccd8/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json

At the moment, osv-scanner is still reporting the latest time crate as vuln to this GHSA. Maybe it hasn't sync'd yet. There systems dont appear to show a sync timestamp for each data source.

However in the JSON, the first affected range is "introduced": "0.1" without a "fixed", but having a database specific "last_known_affected_version_range": "< 0.2". I fear that without a "fixed", this GHSA is still going to seen by osv-scanner as affecting the fixed versions of the crate.

And the following appears three times in the JSON - surely there is no value in having repeated entries in the JSON:

    {
      "package": {
        "ecosystem": "crates.io",
        "name": "time"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0.2.7"
            },
            {
              "fixed": ">= 0.2.23"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "< 0.2.23"
      }
    },

[chrisbloom7]

Yeah, so... 😳 I fixed the wrong bug. Sorta. I mean I fixed some bugs that were definitely bugs, but I missed the bigger one. That's also been fixed now and you'll see that https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2021/08/GHSA-wcg3-cvx6-7396/GHSA-wcg3-cvx6-7396.json has been updated again to remove those bad affected packages. I think we've got everything back where it should be now. Thanks for staying on top of this!

[chrisbloom7]

regarding:

      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0.1"
            }
          ]
        }
      ],
      "database_specific": {
        "last_known_affected_version_range": "< 0.2"
      }

Let me check in with one of the curators. I know we've been talking about a similar issue on another advisory.

[chrisbloom7]

When we have an affected product with no known fix then we'll see that notation "last_known_affected_version_range": "< 0.2". It doesn't happen often, but it can happen for various legitimate reasons. One of our curators, @darakian, took another look at it and added the 0.2.23 version as a fix which he noted is called out as the fix for 0.1 users. The advisory OSV file has been updated with the new info as well as on github.com/advisories.

[jayvdb]

osv-scanner now works without this record being ignored! yay, thanks to all who helped.

It's been five days since b010a65, and nobody else in Rust world noticed / cared enough to give feedback here. :/