More details on the EOL for S/w

[sdinesh17]

Is your feature request related to a problem? Please describe.

Thank you for bringing this project. This work is commendable since you're solving a very important problem. The data available in public domain is scattered and very inconsistent. This project solves that problem. Can we think of a way how we can get this information from vendors on a periodical basis.

Describe the solution you'd like
CIS is providing some info https://www.cisecurity.org/insights/blog/end-of-support-software-report-list but not all. How can we bring this project at the scale of how the NVD/CVE Mitre operates for the CVE related information.
As the backend database updates, can a feed be published on a daily/weekly basis?

Describe alternatives you've considered
Not that i'm aware of except searching for info on the internet.
Some kind of webscrapping/crawling and update the information in the endoflife DB.

Additional context
Vuln mgmt is a crucial part of Secure development Lifecycle. Keeping the OSS upto date is also equally important.

[welcome]

Thank you for opening your first issue here. 👍 Be sure to follow the issue template if you chose one.

[captn3m0]

Thanks for the praise 🤗.

It's unclear what the ask is here. We already publish our data as part of an API: https://endoflife.date/docs/api. We could perhaps do a regular release as well, in some format (probably a dump of our JSON files?)

Feed are already planned (#48, #59)

For the "automatically get this information from vendors", we have a dual solution:

1. We already have a release-data repository that automatically updates known releases. Patch releases are automatically updated on the website once a day, and major releases are added manually. (See Automation on our Wiki). This already covers more than half of the products we track.
2. A long term plan is to have a releases.json standard (See this comment) that would let vendors publish their EOL+release information programatically for any tools to scrape and use.

[sdinesh17]

Thanks for the praise 🤗.

It's unclear what the ask is here. We already publish our data as part of an API: https://endoflife.date/docs/api. We could perhaps do a regular release as well, in some format (probably a dump of our JSON files?)

Feed are already planned (#48, #59)

For the "automatically get this information from vendors", we have a dual solution:

1. We already have a release-data repository that automatically updates known releases. Patch releases are automatically updated on the website once a day, and major releases are added manually. (See Automation on our Wiki). This already covers more than half of the products we track.
2. A long term plan is to have a releases.json standard (See this comment) that would let vendors publish their EOL+release information programatically for any tools to scrape and use.

Thanks @captn3m0 . Good to know. I'm thinking out loud. My point is, how can we expand the scope of getting relevant data in a phased manner.

1. To start with, can we start consuming the data published by the major s/w vendor's products and their EOL.
2. Next to the Common Databases, O/s, etc.
3. Apache or related projects info (or may be all the projects)
4. ..so on..

[captn3m0]

Here's my phased plan:

1. Add support for EOL dates in the data fetched by release-data scripts. For this we need to first decide on the schema a little bit. So this lets us scrape the EOL/Support information from places where it is available easily.
2. Start using that while automatically updating the data in this repo (latest.py here).
3. Publish a specification for a releases.json schema that can be used by websites to publish this automatically. Graduate our API to the spec, so projects can do a 302 redirect from example.com/.well-known/releases.json to endoflife.date/api/example.json and delegate it for now.
4. Publicize the specification, to get other projects on board.

Hopefully once there is a specification, and enough users - this project can become a "registry" of such known URLs.

[sdinesh17]

Here's my phased plan:

1. Add support for EOL dates in the data fetched by release-data scripts. For this we need to first decide on the schema a little bit. So this lets us scrape the EOL/Support information from places where it is available easily.
2. Start using that while automatically updating the data in this repo (latest.py here).
3. Publish a specification for a releases.json schema that can be used by websites to publish this automatically. Graduate our API to the spec, so projects can do a 302 redirect from example.com/.well-known/releases.json to endoflife.date/api/example.json and delegate it for now.
4. Publicize the specification, to get other projects on board.

Hopefully once there is a specification, and enough users - this project can become a "registry" of such known URLs.

Thank you Captn3m0, this really helps. And thanks for all your efforts in addressing this "large supply-chain" and "big-data" issue.

[captn3m0]

Better tracked with #2108