fix(config): refresh openSUSE Leap EOL entries (add 16.0, extend 15.6)#2543
Merged
Conversation
GetEOL returned found=false for `family=opensuse.leap, release=16.0`
because the OpenSUSELeap branch only knew about 15.x and earlier. As a
result, scans on Leap 16.0 hosts emit:
Failed to check EOL. Register the issue to https://github.com/...
`Family: opensuse.leap Release: 16.0`
Add 16.0 with StandardSupportUntil 2027-10-31. Source:
https://en.opensuse.org/Lifetime — "openSUSE Leap 16.0 - maintained
until at least October 2027" (24-month policy from the 2025-10-01
release). Day-of-month follows the existing convention of using the
final day of the stated month.
The Leap-release RPM also ships product-endoflife() = 2026-10-31, but
that is the conservative initial value tied to the next minor release
and is expected to be extended later (Leap 15.6 saw the same pattern,
with its EOL rescheduled from 2025-12-31 to 2026-04-30 after the wiki
update).
Note: this only silences the warning; CheckEOL appends to r.Warnings
and does not gate detection. The 0-CVE result reported in #2539 is a
separate issue (upstream SUSE OVAL platform-check bug) tracked
elsewhere.
Refs #2539
The shipped 15.6 EOL of 2025-12-31 was the date in the original release announcement. It was later rescheduled to align with the new 24-month Leap policy: - https://en.opensuse.org/Lifetime — "openSUSE Leap 15.6 — maintained until at least April 2026" - https://news.opensuse.org/2026/04/01/leap-15-eol/ — "Leap 15.6 will reach End of Life (EOL) at the close of this month" (article dated 2026-04-01, so EOL = 2026-04-30) Day-of-month uses the last day of the stated month, matching the rest of the table. Refs #2539
Contributor
There was a problem hiding this comment.
Pull request overview
Adds openSUSE Leap 16.0 to the OS EOL lookup table so config.GetEOL recognizes family=opensuse.leap, release=16.0 and no longer emits the “Failed to check EOL” warning for Leap 16.0 scan results (refs #2539).
Changes:
- Extend
GetEOL’sconstant.OpenSUSELeapEOL map with a Leap16.0entry. - Set Leap 16.0
StandardSupportUntilto2027-10-31 23:59:59 UTC.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
shino
changed the title
Match the existing supported/eol-since pattern used for other distributions (Fedora, FreeBSD, etc.). Covers: - Leap 15.6 supported on 2026-04-30 - Leap 15.6 eol on 2026-05-01 (after the rescheduled 2026-04-30 EOL) - Leap 16.0 supported on 2026-05-07 (current date) - Leap 16.0 eol on 2027-11-01 (after the 2027-10-31 wiki commitment) The OpenSUSELeap branch had no test coverage previously; this also backfills the bare minimum so future changes to that branch surface in the test suite.
Per Copilot review on #2543: the Fedora/etc. tests in this table use StandardSupportUntil itself as the "supported" now (inclusive boundary) and the next-day 00:00:00 as the "eol since" now. The new Leap cases were using 00:00:00 on the EOL date for the supported case, which would not catch an off-by-one regression in IsStandardSupportEnded (uses now.After(SSU)). Adjust: - "Leap 15.6 supported": now = 2026-04-30 23:59:59 UTC (= SSU itself) - "Leap 15.6 eol since 2026-5-1": (renamed; same now value) - "Leap 16.0 supported": now = 2027-10-31 23:59:59 UTC (= SSU itself) - "Leap 16.0 eol since 2027-11-1": (renamed; same now value)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What did you implement
Two related EOL-table updates for
constant.OpenSUSELeapinconfig.GetEOL, plus the test cases that were missing for that branch:Add
16.0withStandardSupportUntil = 2027-10-31.GetEOLpreviously returnedfound=falsefor any Leap release after 15.6, so scans on Leap 16.0 hosts always emitted:Extend
15.6from2025-12-31to2026-04-30. The original 15.6 entry used the announcement-time date; openSUSE later rescheduled the EOL to align with the new 24-month Leap policy.Add tests for 15.6 and 16.0 (supported / eol-since pairs), matching the existing pattern used for Fedora, FreeBSD, etc. The OpenSUSELeap branch had no
TestEOL_IsStandardSupportEndedcoverage previously.Day-of-month uses the last day of the stated month, matching the existing convention in the table.
Sources
For 16.0:
Leap-releaseRPM declaresproduct-endoflife() = 2026-10-31, but that's the conservative initial value tied to the next minor release and is expected to be extended later (15.6 saw the same pattern, see below). The wiki commitment is the value tracked here.For 15.6:
Refs #2539.
Note
This PR addresses only the EOL warning. The "0 CVEs detected on Leap 16.0" symptom in the same issue is a separate, upstream-SUSE OVAL data bug (
rpminfo_testhard-codesopenSUSE-releaseas the platform package, but Leap 16.0 shipsLeap-releaseand obsoletes the old name). That is being reported tosecurity@suse.comseparately.CheckEOLonly appends tor.Warningsand does not gate detection, so this PR does not change CVE counts.Type of change
How Has This Been Tested?
make fmtgo test ./config/...— passes, including the four new Leap cases:openSUSE_Leap_15.6_supportedopenSUSE_Leap_15.6_eol_since_2026-04-30openSUSE_Leap_16.0_supportedopenSUSE_Leap_16.0_eol_since_2027-10-31Manual repro / verification with a real Leap 16.0 scan result is the same workflow as in #2539:
Checklist
make fmtgo test ./config/...Is this ready for review?: NO (draft — opening for visibility while the related vuls-data-update workaround for the OVAL bug is being discussed)