Distinct PURLs/Identifiers for each release cycle

[captn3m0]

While most products will have a common PURL or identifier for each of the release cycles, this isn't always true.

See the following pages for example:

1. opensuse, where we track SUSE and Leap releases together.
2. centos, where we decided to split up CentOS Stream
3. iPhones and most other devices, where each device has a distinct "list of CPE" identifiers.
4. AWS Lambda Runtimes, where if we combine all of the runtimes in a single page, there will be shared identifiers across some subset of the release cycles (All of nodejs cycles will include it for eg).

Probably a few more. My suggestion is to support a identifiers key underneath releases that overrides the usual identifiers key. We can use YAML Anchors/Aliases to share identifiers between several release cycles.

This would enable tooling to use more specific and accurate identifiers.

cc @noqcks

[noqcks]

Totally agree with per cycle CPEs or PURLs. Right now in xeol for our database, PURLs are at the Product level, same as what it's currently like for endoflife.date, but we'd support it to be scoped per Cycle if endoflife.date made this change.

Somewhat related to this discussion, I was fooling around with an EOL schema that would be extensible enough to handle a lot of use cases. This is really a half-baked schema that I was mucking around with, based loosely from the osv.dev schema.

Hard problems to handle with a schema:

• Vendors might not use semver
• Vendor may have 0 to n extended support options
• A "Product" may contain "Packages" which are not supported under their EOL policy. Examples are Confluent Platform Platinum support not extending the support timeline for Confluent for Kubernetes (CFK) / Operator or at the operating system level only certain packages being supported as is the case with RHEL.

These are just a few, im sure you have many more in mind.

{
  "schema_version": "1.2.0",
  "id": "EOL-c3g4-w6cv-6v7h",
  "modified": "2022-04-01T13:56:42Z",
  "published": "2022-04-01T13:56:42Z",
  "product_name": "Red Hat Enterprise Linux",
  "product_version": "9.2",
  "released": "2022-05-17",
  "lts": false,
  "affected": [
    {
      "package": {
        "ecosystem": "os",
        "identifier:": "cpe:/o:redhat:enterprise_linux:9.2"
      },
      "support_level": {
        "name": "Standard Support",
        "level": 0
      },
      // is updated to be the date when 9.3 is released, since a product instantly becomes EOL
      // when a new version is released on Full Support
      "eol_date": "2023-07-31"
    },
    {
      "package": {
        "ecosystem": "os",
        "identifier:": "cpe:/o:redhat:enterprise_linux:9.2"
      },
      "support_level": {
        "name": "Extended Update Support (EUS)",
        "level": 1
      },
      // EUS is available for 24 months from the availability of the minor release
      "eol_date": "2024-05-17"
    },
    {
      "package": {
        "ecosystem": "os",
        "identifier:": "cpe:/o:redhat:enterprise_linux:9.2"
      },
      "support_level": {
        "name": "Enhanced Extended Update Support (Enhanced EUS)",
        "level": 2
      },
      // Enhanced EUS is available for 48 months from the availability of the minor release
      "eol_date": "2026-05-17"
    }
  ]
}

I haven't been following along with the endoflife.date API work very closely, but imo it would be extremely powerful if you could submit a PURL or CPE with a support level and get back an EOL date for your product, just like how osv.dev API works for vulns. Xeol does all this matching inside the tool, but really it should be in an well-defined API imo.

[captn3m0]

Not sure if you've seen endoflife-date/releases.json#1, but it is fairly similar in scope and schema to what you've suggested.

Curious how you're planning on using the "support level" numbers in xeol. It seems like a cleaner approach to give each support level a unique identifier (int here) to let consumers "set" their level of support. Better than whatever I had in mind in the above spec, will probably incorporate this.

[captn3m0]

Adding constraints via included/excluded packages is probably better handled elsewhere, but I'll think more about this.