Tracking ticket for low-quality CVE reports swamping Bugzilla #23

New issue

Open

opened 2026-09-16 10:48:13 +00:00 by salimma · 3 comments

salimma commented 2026-09-16 10:48:13 +00:00

Member

Copy link

Previously shared in this Google Doc

TL;DR

We would like to get packagers to take CVE bugs more seriously, but that is difficult given the current issues - we also risk training maintainers to ignore Bugzilla altogether (and we know for some parts of Fedora, sadly maintainers are already doing this, e.g. in GNOME)

Choices

Ideally we would like the official scanning tool to address these issues, and a clear target date of when such improvements will land.

There has been communicated concerns that given Bugzilla might be replaced with something else soon, investing in improvements now will require changes down the road. In the last meeting Security SIG members' consensus seems to be that this should not be a blocker, given a lot of the changes are not specific to the issue tracker used, and that (I don't normally like saying this) LLM assistance makes adding support for a new forge / tracker not too complicated anyway

If there is no clear timeline or we think it will take too long, a fallback would be to ask for a way to opt out specific packages (or packagers) from getting CVE bugs

Main tracker

CVE-INVALID

Bugs directly blocking this tracker are triaged by hand by packagers; bugs blocking the other sub-trackers below tend to be classified by fedora-cve-triage (which as a nuclear option, can be extended to be the new tool used to file CVE bugs)

Specific issues

CVE-AlreadyFixed

These are bugs that, when filed, there is already an update in Bodhi for the version addressing the CVE.

Actionable suggestion: the process for filing the bug should also check Bodhi, and modify the update to link the CVE bug (and potentially modify the type to security as well)

Also actionable Even if the CVE was unaddressed at the time the issue was filed, we should probably clean up existing CVEs in case the maintainer does not close the bug, if the issue is already addressed

CVE-FalsePositive-BundledLibrary

These are for issues that falsely assumed that the target component bundled the affected library, when in fact it is dynamically linked and so the downstream dependent does not need to be rebuilt

CVE-FalsePositive-CrossEcosystem

e.g. Python and Rust packages have the same upstream project name; a CVE for the Python package gets filed against the Rust package instead

Actionable use PURL and/or other metadata provided by the Fedora package (e.g. python3dist(...), crate(...) to better identify the target package

CVE-FalsePositive-Interpreter

The issue affects an interpreter (e.g. Python, Ruby) not the package that is merely invoking it

CVE-FalsePositive-

CVE-FalsePositive-Unshipped

These are filed against CVEs that might actually exist in the source tarball, but for code that is never shipped (e.g. Meta's C++ project tarballs - such as cachelib - typically include the website code, which contains JS, and gets multiple issues filed against them per week; this code is never shipped)

CVE-Misfiled-Version

Misfiled version, e.g. CVEs filed against EPEL seem to be filed against the latest epel (epel10) even for packages that are only shipped for older versions, e.g. epel9 or epel8

CVE-Rejected

The CVE was withdrawn and is no longer valid

Previously shared in this [Google Doc](https://docs.google.com/document/d/1e9QtYqct8RaRvmLhCJydEt8_rARIW6IAfQYinAdcyn8/edit?usp=sharing) ## TL;DR We would like to get packagers to take CVE bugs more seriously, but that is difficult given the current issues - we also risk training maintainers to ignore Bugzilla altogether (and we know for some parts of Fedora, sadly maintainers are already doing this, e.g. in GNOME) ## Choices Ideally we would like the official scanning tool to address these issues, and a clear target date of when such improvements will land. There has been communicated concerns that given Bugzilla might be replaced with something else soon, investing in improvements now will require changes down the road. In the last meeting Security SIG members' consensus seems to be that this should not be a blocker, given a lot of the changes are not specific to the issue tracker used, and that (I don't normally like saying this) LLM assistance makes adding support for a new forge / tracker not too complicated anyway If there is no clear timeline or we think it will take too long, a fallback would be to ask for a way to opt out specific packages (or packagers) from getting CVE bugs ## Main tracker [CVE-INVALID](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-INVALID) Bugs directly blocking this tracker are triaged by hand by packagers; bugs blocking the other sub-trackers below tend to be classified by [`fedora-cve-triage`](https://github.com/slopfest/sandogasa/tree/main/tools/fedora-cve-triage) (which as a nuclear option, can be extended to be the new tool used to file CVE bugs) ## Specific issues ### [CVE-AlreadyFixed](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-AlreadyFixed) These are bugs that, when filed, there is already an update in Bodhi for the version addressing the CVE. **Actionable suggestion:** the process for filing the bug should also check Bodhi, and modify the update to link the CVE bug (and potentially modify the type to security as well) **Also actionable** Even if the CVE was unaddressed at the time the issue was filed, we should probably clean up existing CVEs in case the maintainer does not close the bug, if the issue is already addressed ### [CVE-FalsePositive-BundledLibrary](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-FalsePositive-BundledLibrary) These are for issues that falsely assumed that the target component bundled the affected library, when in fact it is dynamically linked and so the downstream dependent does not need to be rebuilt ### [CVE-FalsePositive-CrossEcosystem](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-FalsePositive-CrossEcosystem) e.g. Python and Rust packages have the same upstream project name; a CVE for the Python package gets filed against the Rust package instead **Actionable** use PURL and/or other metadata provided by the Fedora package (e.g. python3dist(...), crate(...) to better identify the target package ### [CVE-FalsePositive-Interpreter](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-FalsePositive-Interpreter) The issue affects an interpreter (e.g. Python, Ruby) not the package that is merely invoking it ### [CVE-FalsePositive-](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-FalsePositive-) ### [CVE-FalsePositive-Unshipped](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-FalsePositive-Unshipped) These are filed against CVEs that might actually exist in the source tarball, but for code that is never shipped (e.g. Meta's C++ project tarballs - such as cachelib - typically include the website code, which contains JS, and gets multiple issues filed against them per week; this code is never shipped) ### [CVE-Misfiled-Version](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-Misfiled-Version) Misfiled version, e.g. CVEs filed against EPEL seem to be filed against the latest epel (epel10) even for packages that are only shipped for older versions, e.g. epel9 or epel8 ### [CVE-Rejected](https://bugzilla.redhat.com/show_bug.cgi?id=CVE-Rejected) The CVE was withdrawn and is no longer valid

❤️ 2

py0xc3 added the

meeting

label 2026-09-16 12:01:44 +00:00

jazinner commented 2026-09-17 05:13:30 +00:00

Copy link

Fedora/EPEL manifesting: Deptopia then, koji-sbom now

How Red Hat Product Security inventories Fedora and EPEL packages for CVE tracker filing, and how recent changes relate to the invalid-CVE categories on that ticket.

Summary of architectural changes

	Previously (Deptopia)	Now (koji-sbom pipeline)
Fedora streams scanned	fedora-rawhide and numbered releases (fedora-42, fedora-43, fedora-44, …)	fedora-rawhide only — not fedora-44, fedora-43, or fedora-42
EPEL streams scanned	epel-8, epel-9, epel-10	Same
How we find packages	dnf repoquery on yum repos → latest source NVRs → Fedora Koji	Same
How we find bundled deps	Download SRPM, prep sources, run deplist (software composition analysis) on the source tree; merge with RPM Provides	No SCA. No SRPM download, no Syft, no deplist. Read Provides: from RPM headers via Koji (bundled(), golang(), python3dist(), crate(), …) — the same metadata packagers declare in the spec at build time (Fedora bundling guidelines, security-data-guidelines)
Bugzilla filing	Scan per release, but collapse to one tracker: a single fedora-all bug per CVE (not one bug per Fedora version); same pattern for EPEL with epel-all	Fedora: still fedora-all but now fedora-all is an alias for fedora-rawhide. EPEL: open question below

For contrast, RHEL platform RPMs today still use Syft on unpacked SRPMs plus Koji Provides. The Fedora/EPEL community path deliberately does not.

koji-sbom does not parse .spec files on disk. Packager Provides: land on binary RPM headers at build time; we read those from Koji.

Pipeline overview

Previously: yum repos → Fedora Koji → download SRPM → deplist on prepped source → internal manifest database → CVE matching → Bugzilla.

Now: yum repos → Fedora Koji (metadata only) → koji-sbom SPDX → staged in a GCS bucket → assembled into a query database → internal query service (bomq, behind the Red Hat firewall) → CVE matching → Bugzilla.

Openness and where the SBOMs live

• koji-sbom is open source (Apache 2.0). Anyone can generate the same SPDX from Fedora Koji, e.g. koji-sbom --namespace fedora <NVR>.
• Generated SBOMs are staged in a GCS bucket (Red Hat employee-visible today; can be made public).
• bomq is a read-only query service that runs inside the Red Hat firewall; it does not crawl Koji. We plan to publish bomq as open source after some tidy-up. The collection/assemble pipeline itself stays internal.

---

For each specific issue: what we used to do, what we do now, and what that does or does not fix.

CVE-AlreadyFixed

Then: We inventoried rawhide and F42/F43/F44 (and each EPEL). A CVE could match a stable NVR that already had a Bodhi update. We did not consult Bodhi, so bugs were still filed; maintainers closed them as already fixed.

Now: We still inventory rawhide, but we no longer inventory numbered Fedora releases. Fedora matching is against rawhide only — a fix already in F43/F44 Bodhi is no longer a reason to file a per-release Fedora bug.

We are not adding a Bodhi check for Fedora: rawhide auto-updates go stable in minutes, so the NVR in the rawhide yum repo we already scan is the latest shipped build. We still do not attach CVE bugs to existing Bodhi updates or auto-close the historical AlreadyFixed pile.

CVE-FalsePositive-BundledLibrary

Then: deplist walked unpacked sources and often treated a dynamically linked library as bundled. We tried to filter hits against RPM Requires; that was incomplete.

Now: We only record components the spec declared as bundled (Provides: bundled(...), etc.). A package that Requires: libfoo and does not provide bundled(libfoo) will not get a bundled libfoo entry.

Caveat: A wrong bundled() in the spec still becomes an inventory entry. Undeclared vendored code is not discovered — that is the packager contract, not a scanner gap.

CVE-FalsePositive-CrossEcosystem

Then: Name-only matching (same project name in PyPI vs crates.io) filed a Python CVE against a Rust package, and vice versa.

Now: RPM Provides are mapped to typed PURLs (pkg:pypi/…, pkg:cargo/…, pkg:golang/…, pkg:npm/…, …) from python3dist(…), crate(…), golang(…), etc. Matching can require ecosystem, not just the short name.

Caveat: Generic bundled(foo) stays pkg:generic/foo and can still collide if filing ignores PURL type.

CVE-FalsePositive-Interpreter

Then: SCA of a package that merely invokes Python/Ruby often attributed interpreter CVEs to that package.

Now: We do not scan interpreter stdlib or lockfiles inside the tarball. A package that only Requires: python3 is not given bundled Python components. Interpreter CVEs belong on the interpreter RPM unless the spec declares a bundled copy.

CVE-FalsePositive-Unshipped

Then: deplist saw everything in the source tarball (e.g. website JS inside Meta C++ tarballs). Multiple bugs per week against code Fedora never ships.

Now: We never unpack the tarball. Unshipped website/test/docs trees do not appear unless the spec Provides: bundled(…) them. This is the largest win from turning off SCA.

CVE-Rejected

Then / now: Inventory does not know when a CVE is withdrawn. Skipping rejected IDs is a filing-time check against the CVE record, unchanged by this approach.

CVE-Misfiled-Version (open question for the SIG)

Then: EPEL 8/9/10 were inventoried separately, but filing was collapsed into a single epel-all Bugzilla tracker — one bug per CVE, not one per EPEL version. That tracker is not tied to a specific EPEL release, so bugs could look like they were filed on latest EPEL even when the package only exists on epel-8 or epel-9.

Now: We still produce separate inventories for epel-8, epel-9, and epel-10 (a package only on epel-8 is visible as such). We can file one tracker per EPEL version that actually ships the package, or keep collapsing to epel-all.

Question for the SIG:

Should we file a Bugzilla tracker for each EPEL version that actually ships the package (epel-8, epel-9, epel-10), or continue collapsing all EPEL hits into a single epel-all tracker as we have been doing?

Per-version trackers are more accurate and avoid epel-10 noise for epel-8-only packages, but multiply bug volume. epel-all is less mail but can repeat the misfiled-version problem.

Fedora we have designed the new approach with only fedora-rawhide: we used to scan rawhide and F44/F43/F42 but file one fedora-all tracker; we now scan rawhide only and still file the collapsed fedora-all tracker.

---

Relation to this ticket's broader choices

• These improvements are tracker-agnostic (PURL typing, spec Provides, which streams we inventory). They are not wasted if Bugzilla is replaced.
• koji-sbom is already public; bomq is the only further open-source publication planned. We can make the GCS bucket public as well once the switch to the architecture is approved.
• Per-package or per-maintainer opt-out is a filing policy decision, not an SBOM-generation change.

# Fedora/EPEL manifesting: Deptopia then, koji-sbom now How Red Hat Product Security inventories Fedora and EPEL packages for CVE tracker filing, and how recent changes relate to the invalid-CVE categories on that ticket. ## Summary of architectural changes | | **Previously (Deptopia)** | **Now (koji-sbom pipeline)** | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Fedora streams scanned** | `fedora-rawhide` and numbered releases (`fedora-42`, `fedora-43`, `fedora-44`, …) | `fedora-rawhide` **only** — not `fedora-44`, `fedora-43`, or `fedora-42` | | **EPEL streams scanned** | `epel-8`, `epel-9`, `epel-10` | Same | | **How we find packages** | `dnf repoquery` on yum repos → latest source NVRs → Fedora Koji | Same | | **How we find bundled deps** | Download SRPM, prep sources, run **[deplist](https://github.com/RedHatProductSecurity/deplist)** (software composition analysis) on the source tree; merge with RPM `Provides` | **No SCA.** No SRPM download, no Syft, no deplist. Read `Provides:` **from RPM headers** via Koji (`bundled()`, `golang()`, `python3dist()`, `crate()`, …) — the same metadata packagers declare in the spec at build time ([Fedora bundling guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling), [security-data-guidelines](https://github.com/RedHatProductSecurity/security-data-guidelines)) | | **Bugzilla filing** | Scan per release, but **collapse to one tracker**: a single `fedora-all` bug per CVE (not one bug per Fedora version); same pattern for EPEL with `epel-all` | Fedora: still `fedora-all` but now fedora-all is an alias for `fedora-rawhide`. EPEL: open question below | For contrast, RHEL platform RPMs today still use [Syft](https://github.com/anchore/syft) on unpacked SRPMs plus Koji `Provides`. The Fedora/EPEL community path deliberately does not. [koji-sbom](https://github.com/RedHatProductSecurity/koji-sbom) does not parse `.spec` files on disk. Packager `Provides:` land on binary RPM headers at build time; we read those from Koji. ## Pipeline overview **Previously:** yum repos → Fedora Koji → download SRPM → deplist on prepped source → internal manifest database → CVE matching → Bugzilla. **Now:** yum repos → Fedora Koji (metadata only) → **[koji-sbom](https://github.com/RedHatProductSecurity/koji-sbom)** SPDX → staged in a GCS bucket → assembled into a query database → internal query service (**bomq**, behind the Red Hat firewall) → CVE matching → Bugzilla. ### Openness and where the SBOMs live - **[koji-sbom](https://github.com/RedHatProductSecurity/koji-sbom) is open source** (Apache 2.0). Anyone can generate the same SPDX from Fedora Koji, e.g. `koji-sbom --namespace fedora <NVR>`. - Generated SBOMs are staged in a **GCS bucket** (Red Hat employee-visible today; **can be made public**). - **bomq** is a read-only query service that runs inside the Red Hat firewall; it does not crawl Koji. We **plan to publish bomq as open source** after some tidy-up. The collection/assemble pipeline itself stays internal. --- For each specific issue: what we used to do, what we do now, and what that does or does not fix. ### CVE-AlreadyFixed **Then:** We inventoried rawhide *and* F42/F43/F44 (and each EPEL). A CVE could match a stable NVR that already had a Bodhi update. We did not consult Bodhi, so bugs were still filed; maintainers closed them as already fixed. **Now:** We still inventory **rawhide**, but we **no longer inventory numbered Fedora releases**. Fedora matching is against rawhide only — a fix already in F43/F44 Bodhi is no longer a reason to file a per-release Fedora bug. We are **not** adding a Bodhi check for Fedora: rawhide auto-updates go stable in minutes, so the NVR in the rawhide yum repo we already scan is the latest shipped build. We still do not attach CVE bugs to existing Bodhi updates or auto-close the historical AlreadyFixed pile. ### CVE-FalsePositive-BundledLibrary **Then:** deplist walked unpacked sources and often treated a **dynamically linked** library as bundled. We tried to filter hits against RPM `Requires`; that was incomplete. **Now:** We only record components the spec **declared** as bundled (`Provides: bundled(...)`, etc.). A package that `Requires: libfoo` and does not provide `bundled(libfoo)` will not get a bundled `libfoo` entry. **Caveat:** A wrong `bundled()` in the spec still becomes an inventory entry. Undeclared vendored code is not discovered — that is the packager contract, not a scanner gap. ### CVE-FalsePositive-CrossEcosystem **Then:** Name-only matching (same project name in PyPI vs crates.io) filed a Python CVE against a Rust package, and vice versa. **Now:** RPM `Provides` are mapped to **typed PURLs** (`pkg:pypi/…`, `pkg:cargo/…`, `pkg:golang/…`, `pkg:npm/…`, …) from `python3dist(…)`, `crate(…)`, `golang(…)`, etc. Matching can require ecosystem, not just the short name. **Caveat:** Generic `bundled(foo)` stays `pkg:generic/foo` and can still collide if filing ignores PURL type. ### CVE-FalsePositive-Interpreter **Then:** SCA of a package that merely *invokes* Python/Ruby often attributed interpreter CVEs to that package. **Now:** We do not scan interpreter stdlib or lockfiles inside the tarball. A package that only `Requires: python3` is not given bundled Python components. Interpreter CVEs belong on the interpreter RPM unless the spec declares a bundled copy. ### CVE-FalsePositive-Unshipped **Then:** deplist saw **everything in the source tarball** (e.g. website JS inside Meta C++ tarballs). Multiple bugs per week against code Fedora never ships. **Now:** We never unpack the tarball. Unshipped website/test/docs trees do not appear unless the spec `Provides: bundled(…)` them. This is the largest win from turning off SCA. ### CVE-Rejected **Then / now:** Inventory does not know when a CVE is withdrawn. Skipping rejected IDs is a filing-time check against the CVE record, unchanged by this approach. ### CVE-Misfiled-Version (open question for the SIG) **Then:** EPEL 8/9/10 were inventoried separately, but filing was **collapsed into a single** `epel-all` **Bugzilla tracker** — one bug per CVE, not one per EPEL version. That tracker is not tied to a specific EPEL release, so bugs could look like they were filed on latest EPEL even when the package only exists on epel-8 or epel-9. **Now:** We still produce **separate inventories** for epel-8, epel-9, and epel-10 (a package only on epel-8 is visible as such). We *can* file one tracker per EPEL version that actually ships the package, or keep collapsing to `epel-all`. **Question for the SIG:** > Should we file a Bugzilla tracker for each EPEL version that actually ships the package (epel-8, epel-9, epel-10), or continue collapsing all EPEL hits into a single `epel-all` tracker as we have been doing? Per-version trackers are more accurate and avoid epel-10 noise for epel-8-only packages, but multiply bug volume. `epel-all` is less mail but can repeat the misfiled-version problem. **Fedora** we have designed the new approach with only fedora-rawhide: we used to scan rawhide and F44/F43/F42 but file one `fedora-all` tracker; we now scan **rawhide only** and still file the collapsed `fedora-all` tracker. --- ## Relation to this ticket's broader choices - These improvements are **tracker-agnostic** (PURL typing, spec `Provides`, which streams we inventory). They are not wasted if Bugzilla is replaced. - **koji-sbom is already public**; **bomq** is the only further open-source publication planned. We can make the GCS bucket public as well once the switch to the architecture is approved. - Per-package or per-maintainer opt-out is a **filing policy** decision, not an SBOM-generation change.

salimma commented 2026-09-24 11:00:26 +00:00

Author

Member

Copy link

Today's crop: I cut libheif updates in the wee hours of Sep 23 (UTC+1) / late on Sep 22 US time, and while all the updates are already in Bodhi but not stable, these fired

Fixes in testing or pending (15):                                                  
  bug 2539256 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539257 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)            
  bug 2539258 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539259 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)            
  bug 2539260 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539261 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)            
  bug 2539263 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539264 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)            
  bug 2539265 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539266 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)
  bug 2539267 — libheif-1.23.5-1.el9 (FEDORA-EPEL-2026-12b7f6fc6c, testing)        
  bug 2539268 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)     
  bug 2539269 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)
  bug 2539270 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing)       bug 2539271 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing)

Today's crop: I cut `libheif` updates in the wee hours of Sep 23 (UTC+1) / late on Sep 22 US time, and while all the updates are already in Bodhi but not stable, these fired ``` Fixes in testing or pending (15): bug 2539256 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539257 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539258 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539259 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539260 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539261 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539263 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539264 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539265 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539266 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539267 — libheif-1.23.5-1.el9 (FEDORA-EPEL-2026-12b7f6fc6c, testing) bug 2539268 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539269 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) bug 2539270 — libheif-1.23.5-3.el10_2 (FEDORA-EPEL-2026-3f535077b3, testing) bug 2539271 — libheif-1.23.5-3.fc43 (FEDORA-2026-022ff83e3e, testing) ```

👀 1

salimma commented 2026-09-24 16:05:23 +00:00

Author

Member

Copy link

@jazinner wrote in #23 (comment):

open question

thanks for the thorough reply

for filing epel-all - we're fine with a single CVE filed, but it should not be filed against the latest epel release available in Bugzilla, it should be filed against the latest epel release affected by the issue

e.g. I have seen python-django3 CVE bugs (a package that is only in epel8) being filed against epel10

For CVE-AlreadyFiled - targeting only Rawhide fixes / papers over the issue for Fedora, but looks like it's still affecting CVE bugs filed for EPEL ? Unless the proposal is not in effect yet.

I would argue that given most Fedora packagers historically care less about EPEL than about Fedora proper, low quality submissions against EPEL is actually a /worse/ problem - as it is even more likely to discourage packagers from even giving a damn. libheif illustrates this precisely - EPEL was lagging for months and affected by many, actually real, CVEs. because of low-quality bug fatigue nobody cared to fix it until this week. Then right after updates are published, a few hours later we got hit by new CVE filings... for the bugs addressed by... those updates.

@jazinner wrote in https://forge.fedoraproject.org/security/tickets/issues/23#issuecomment-1357763: > open question thanks for the thorough reply for filing epel-all - we're fine with a single CVE filed, but it should not be filed against the latest epel release available in Bugzilla, it should be filed against the latest epel release affected by the issue e.g. I have seen python-django3 CVE bugs (a package that is only in epel8) being filed against epel10 For CVE-AlreadyFiled - targeting only Rawhide fixes / papers over the issue for Fedora, but looks like it's still affecting CVE bugs filed for EPEL ? Unless the proposal is not in effect yet. I would argue that given most Fedora packagers historically care less about EPEL than about Fedora proper, low quality submissions against EPEL is actually a /worse/ problem - as it is even more likely to discourage packagers from even giving a damn. `libheif` illustrates this precisely - EPEL was lagging for months and affected by many, actually real, CVEs. because of low-quality bug fatigue nobody cared to fix it until this week. Then right after updates are published, a few hours later we got hit by new CVE filings... for the bugs addressed by... those updates.

py0xc3 removed the

meeting

label 2026-10-09 12:23:41 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

  

meeting

No labels

meeting

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

security/tickets#23

No description provided.