plug: automated CLI linter

[mcandre]

Hi,

As mentioned on the gitter chat, I am prototyping a command line linter to scan environments for components that are by their end of life according to your wonderful database.

https://github.com/mcandre/cicada

I like how endoflife organizes the data. Can we please extend the data to include some additionally helpful elements?

• An "os" boolean attribute for products which are operating systems. This helps linters to only scan the OS once, and then proceed to scan the entire rest of available products.
• "posix_query" and "powershell_query" string attributes for products. When executed by POSIX compatible sh interpreter or PowerShell interpreter, the command line queries produce the live product's version number to compare against the support timelines.

Right now, I'm maintaining a local configuration database with this information. But if we promoted the data into the main endoflife database, then I know the community would help to maintain it better than I can individually.

[captn3m0]

1. We have a category: os field on every OS product, but I think that's not exposed currently. This should be easy to fix.
2. The versionCommand parameter is based on what the guidance from upstream is. And these commands often result in additional information.

For eg, running cat etc/os-release already provides too much information in most distros than just the version number. Instead of relying on version commands for automation, my recommendation would be to use existing tooling such as Syft which will accurately report OS, and product versions.

[captn3m0]

This should be easy to fix.

It's a breaking change to our API 😢, but we should still go ahead and do it imo. cc @hugovk thoughts?

https://endoflife.date/api/ubuntu.json should have top level information as well, with a releases field containing what we currently show.

[hugovk]

What sort of breaking change would it be?

[captn3m0]

We go from:

[
  {
    "cycle":"22.04",
    "codename":"Jammy Jellyfish",
...

to maybe something like:

{
  "category": "os",
  "releases": [{""}] // same as earlier
  "releasePolicyLink: ""
  "versionCommand": ""
  "title": "",
  "iconUrl": "//"
}

This would allow us to provide a lot more metadata to the API clients.

[captn3m0]

fwiw, integrating with the SBOM ecosystem is our long-term goal: #763

[hugovk]

Sure, go for it!

Let's co-ordinate releases:

I can use the PR preview to update my API client, and when both are ready, we can merge/release at the same time.

Would it be worth adding a version number to the API itself? Some examples: https://restfulapi.net/versioning/

[captn3m0]

Could do v2 URL change, while keeping the older one as-is. But seeing as how we've marked our API as stable - I don't want to maintain old code.

Will file a PR for feedback 👍

[captn3m0]

@mcandre Just to close out this issue:

1. We'll upgrade our API to include the category field, so you should be able to filter for the operating system. We have a ongoing PR to standardize "os" labels via the PURL schema, so hopefully that can be re-used here. Will file a new issue for this.
2. Not planning to add specific version commands for now, I'd recommend using a proper inventory scanner instead of rolling a new one.

[hugovk]

Could do v2 URL change, while keeping the older one as-is. But seeing as how we've marked our API as stable - I don't want to maintain old code.

Agreed, no need to maintain two versions. 👍

Another option to API version number in URL is putting the version number in a header. The client can be updated to check the version, and if's it newer than expected, tell the user to update the client. Anyway, not super important right now!