[HN Gopher] OpenEoX to Standardize End-of-Life (EOL) and End-of-...
___________________________________________________________________
OpenEoX to Standardize End-of-Life (EOL) and End-of-Support (EOS)
Information
Author : feldrim
Score : 26 points
Date : 2025-05-12 15:02 UTC (7 hours ago)
(HTM) web link (openeox.org)
(TXT) w3m dump (openeox.org)
| feldrim wrote:
| An SBOM-like approach to EOL/EOS issues is on the way.
| rollcat wrote:
| I think the only large projects that presently take SBOMs
| seriously are Nix, Guix, and Go (non-cgo). Bootstrapping is
| non-trivial, but at least builds are reproducible and can be
| compared against existing binaries.
|
| "Oh, just write plain C". Which compiler do you mean? GCC?
| LLVM/clang? On top of what OS/kernel? What firmware? Etc.
| Arnavion wrote:
| Some distros packaging Rust software (OpenSUSE at least) also
| transparently set up CARGO=cargo-audit to get embedded SBOMs.
| wallrat wrote:
| How does this relate to the OWASP/Ecma Common Lifecycle
| Enumeration Specification (https://tc54.org/cle/)?
| wpollock wrote:
| In my experience, many software projects become abandoned and no
| notice is given. I don't see how this standard helps in such
| cases.
| repelsteeltje wrote:
| I think it will take a while for people to realize this effort
| looked great, but wasn't the right approach. Or no silver bullet,
| at least.
|
| The presentation with a simple diagram that combines this data
| with an sbom to yield "information" gives me navel gazing vibes
| of UML being _the future of coding_.
|
| Just as _architecture_ didn 't equate to well designed and
| maintainable software, I fear this initiative won't fix horribly
| outdated and vulnerable deployments. Software life cycle,
| deprecation, abandonment, supply chains are mostly a process
| problem, standards and technology won't fix that.
| Arnavion wrote:
| It doesn't force someone who already wasn't checking their
| dependencies for CVEs / maintained-ness to start doing that. It
| does make someone who *was* doing that be able to show they're
| doing that in some standard way.
|
| In other words it doesn't force you to add an SBOM + EOX
| checker step to your CI pipeline. But if your compliance
| auditor wants you to check your dependencies, adding such a
| standardized step makes it easier to satisfy the auditor.
| repelsteeltje wrote:
| I'm basing this mostly off first hand and anecdotal evidence
| - but through the years I've found that the major
| contribution of audits lies in having to think about the
| checkboxes every now and then. And what they mean in the
| context of my organization or project.
|
| Rarely have I found that compliance to the goals was an issue
| in themselves. Or that making changes to tick a checkbox
| correlated to material improvements.
|
| That is to say that if this leads to more efficiency and
| _makes it easier for compliance audits and such_ , I fear is
| stream lining the least impactful part of its goals.
| hiatus wrote:
| > Rarely have I found that compliance to the goals was an
| issue in themselves. Or that making changes to tick a
| checkbox correlated to material improvements.
|
| I am confused when I hear people say stuff like this. I
| guess if you turn on a tool and never look at it again, it
| won't result in material improvements. But complying with
| regulations or a particular compliance regime should
| _absolutely_ result in at least _some_ material improvement
| to your security posture. Like you can implement
| segregation of duties just as a checkbox, or use the
| requirement to revisit the way you gate changes to
| production, as just one example.
| T3OU-736 wrote:
| Htm. So, how does this compare, and/or is different from
| https://endoflife.date?
| Arnavion wrote:
| The standard is for software to report its own EOL / EOS
| status. The website you linked is the opposite direction - it's
| aggregating that status for a certain set of software.
| T3OU-736 wrote:
| Aha. Very good point. SW self-reporting requires buy-in,
| though, which seems like a pretty high barrier.
|
| I am very much hoping the effort succeeds, but I am also
| mindful of the fact that the site to which I have linked is
| more successful by virtue of having better coverage.
| mud_dauber wrote:
| JEDEC has long maintained an EOL/EOS standard for semiconductors.
| This was a big part of a previous PM gig. Sounds boring, and it
| was. But having a process kept us out of serious hot water.
| Hackbraten wrote:
| That EoX logo though.
|
| Every organization or committee that designs a logo should be
| legally required to have at least one teenager on the board to
| prevent accidental goatse or other inadvertent blunders.
___________________________________________________________________
(page generated 2025-05-12 23:01 UTC)