View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000644 | AlmaLinux-10 | General | public | 2026-07-03 01:45 | 2026-07-14 03:14 |
| Reporter | shino | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Summary | 0000644: AlmaLinux 10: advisories removed from errata.full.json while their HTML pages remain published — which source is authoritative? | ||||
| Description | I help maintain the data pipeline of an open-source vulnerability scanner https://github.com/future-architect/vuls/ , which consumes https://errata.almalinux.org/10/errata.full.json. Around 2026-05-19..26, the AlmaLinux 10 errata feed went through a large re-curation: - Many published ALSA advisories disappeared from errata.full.json. Our snapshot of 2026-05-21 contained 279 advisories; during that window the feed shrank to roughly 60, and it has since regrown to 264 (as of 2026-07-02). - Some advisories were re-issued under new IDs, in some cases more than once. Example: CVE-2025-13601 was covered by ALSA-2026:0975, which disappeared and is now covered by ALSA-2026:18344. - However, the static HTML pages of the removed advisories are still published: they return HTTP 200 with full content, and they are still listed in the directory index at https://errata.almalinux.org/10/ (504 ALSA-*.html files vs 264 entries in the current feed). Impact: comparing our 2026-05-21 snapshot with the current feed, the removed advisories referenced 434 unique CVEs, of which only 58 are still referenced by any advisory in the current feed. The remaining 376 CVEs are no longer covered at all. For downstream consumers of the feed (security scanners, SBOM/VEX tooling), this is an effective loss of detection coverage for AlmaLinux 10, while the same advisories still look "published" on the website. Questions: 1. Was the removal of these advisories from errata.full.json an intentional retirement/re-curation, or a side effect of how the feed is regenerated? 2. Which source should downstream consumers treat as authoritative: errata.full.json, the HTML pages, or the updateinfo.xml shipped in the repositories? 3. If the retirement is intentional, could the corresponding HTML pages be removed or marked as retired, so the two sources stay consistent? Conversely, if it is not intentional, could the feed be regenerated to include them again? 4. Is there any announcement or changelog describing this re-curation that we could reference? Other examples absent from the feed but live as HTML: - https://errata.almalinux.org/10/ALSA-2025-21013.html (libssh) - https://errata.almalinux.org/10/ALSA-2025-23479.html (openssh) - https://errata.almalinux.org/10/ALSA-2026-13515.html (freeipmi) - https://errata.almalinux.org/10/ALSA-2026-3517.html (thunderbird) | ||||
| Steps To Reproduce | 1. Fetch https://errata.almalinux.org/10/errata.full.json and confirm it contains 264 advisories, none of which is e.g. ALSA-2025:20095. 2. Open https://errata.almalinux.org/10/ALSA-2025-20095.html — the page is still live with full content (Moderate: kernel security update). 3. Compare https://errata.almalinux.org/10/ (directory index, 504 ALSA-*.html files) with the feed (264 entries). | ||||
| Additional Information | Happy to provide the full list of affected advisory IDs / CVEs if useful. | ||||
| Tags | security | ||||
|
|
Due to technical reasons we only have errata in json and updateinfo.xml for packages that are in current version's repo. If you need historical data from previous minor releases then probably OVAL is a better option for you: https://security.almalinux.org/oval/ OSV database also contains older advisories, for example: https://osv.dev/vulnerability/ALSA-2025:21013 |
|
|
Thank you for the quick and clear response — and for the OVAL pointer, that helps a lot. We dug into the OVAL and OSV data and have three follow-up questions: 1. ALBS API usage While investigating we noticed that the build system API, e.g. https://build.almalinux.org/api/v1/errata/query/?id=ALSA-2025:20095 returns complete errata records (including the full historical package lists with epoch/arch). It appears to be undocumented, so we do not want to depend on it without asking: is this API considered internal, or is it acceptable for external tools to consume it (at a reasonable request rate)? If it is internal, we will simply not use it. 2. Advisories missing from OVAL Comparing the current org.almalinux.alsa-10.xml (generated 2026-07-13) with errata.full.json, 64 advisories present in the JSON feed are absent from OVAL. Almost all of them are the batch re-issued around 2026-05-26 (the ALSA-2026:18xxx-19xxx range, e.g. ALSA-2026:18344), plus a few issued between 2026-05-11 and 2026-06-16, including two kernel advisories: ALSA-2026:21557 and ALSA-2026:23329. Advisories issued after 2026-06-16 do appear in OVAL, so the gap looks frozen rather than ongoing — but it has not closed in 0000007:0000007 weeks. Is this expected to backfill, or should we report it separately? 3. Recommended combination for our use case Our goal is vulnerability detection for AlmaLinux 8, 9 and 10 hosts (including hosts still running packages from previous minor releases). From what we can see, neither source alone is sufficient: errata.full.json lacks the historical (previous-minor) package data, while OVAL currently lacks the re-issued advisories mentioned above. Is consuming BOTH — OVAL for historical coverage plus errata.full.json for the advisories OVAL is missing — the intended/recommended approach? Thanks again for your help! |
