Best practice: when to use multiple ranges vs. events?

[mbauman]

The OSV schema permits an array of affected[].ranges, and each range can itself have a sequence of discontiguous events. How should multiple ranges of the same type be used? When/why would I use one? Or should they be discouraged?

The OSV schema includes this example:

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "1.0.0" },
      { "fixed": "1.0.2" },
      { "introduced": "3.0.0" },
      { "fixed": "3.2.5" }
    ]
} ]

That could equivalently be expressed as:

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "1.0.0" },
      { "fixed": "1.0.2" },
    ]
}, {
    "type": "SEMVER",
    "events": [
      { "introduced": "3.0.0" },
      { "fixed": "3.2.5" }
    ]
} ]

What if I have a third branch where a release has not yet been cut — and for which I only have a last_affected version? I can't use both fixed and last_affected within the same events array, but can/could/should I use multiple ranges like this?

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "1.0.0" },
      { "fixed": "1.0.2" },
      { "introduced": "3.0.0" },
      { "fixed": "3.2.5" }
    ]
}, {
    "type": "SEMVER",
    "events": [
      { "introduced": "2.0.0" },
      { "last_affected": "2.1.3" }
    ]
} ]

[mbauman]

For a concrete example, I'm struggling with how to best express a vulnerability for a package whose versioning scheme changed. I have versions:

2019.10.23
1.0.0
2.0.0
2.0.1

It went from a date-based number in the shape of a SemVer to a real semantic SemVer. The 2019.10.23 version predates the other three. Yes, I know this is problematic (and within the Julia package manager, this 2019 version has now been "yanked" and is no longer newly installable but may exist and still function in old projects).

Now I have a CVE that applies to all versions prior to 2.0.1. How do I best represent this? I see three possibilities:

Two range objects, one with last_affected and one with fixed:

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "2019.10.23" },
      { "last_affected": "2019.10.23" },
    ]
}, {
    "type": "SEMVER",
    "events": [
      { "introduced": "0" },
      { "fixed": "2.0.1" }
    ]
} ]

Or, describe this with last_affected on both intervals in one events

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "0" },
      { "last_affected": "2.0.0" },
      { "introduced": "2019.10.23" },
      { "last_affected": "2019.10.23" },
    ]
} ]

Or, just plop the historic version number into the versions array:

"versions": ["2019.10.23", "1.0.0", "2.0.0", "2.0.1"],
"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "0" },
      { "fixed": "2.0.1" },
    ]
} ]

[jess-lowe]

For

Two range objects, one with last_affected and one with fixed:

All of these would be technically valid, because there's no overlap between the ranges. Personally, I'd probably recommend 1 or 3 for readability but they're all fine. We don't really have a preference.

For

What if I have a third branch where a release has not yet been cut — and for which I only have a last_affected version? I can't use both fixed and last_affected within the same events array, but can/could/should I use multiple ranges like this?

"ranges": [ {
    "type": "SEMVER",
    "events": [
      { "introduced": "1.0.0" },
      { "fixed": "1.0.2" },
      { "introduced": "3.0.0" },
      { "fixed": "3.2.5" }
    ]
}, {
    "type": "SEMVER",
    "events": [
      { "introduced": "2.0.0" },
      { "last_affected": "2.1.3" }
    ]
} ]

Yes you can do that, no issues. You can also have each version ranges pair in different ranges if you want.