epel

#348 RFC: "incompatible" rust-matchers update in EPEL 10.* to fix CVE-2025-58160
Closed: Deferred by carlwgeorge. Opened by decathorpe.

Closed: Deferred
Reopen Issue

We got a report for a "security vulnerability" in the tracing-subscriber crate, packaged as rust-tracing-subscriber for Fedora and EPEL (CVE-2025-58160). This issue has been fixed in the latest version (0.3.20).

This in itself wouldn't be a problem, but the update from 0.3.19 (which is the current version in all branches of Fedora and EPEL 9 and 10.*) also bumps to a new "major" version of one dependency, the matchers crate (will depend on version 0.2, currently depends on 0.1).

I tried applying the patch for CVE-2025-58160 on top of tracing-subscriber 0.3.19, but it doesn't apply cleanly - there were other changes between 0.3.19 and 0.3.20, and the patch we need is the last one before the 0.3.20 release. It also doesn't necessarily look straightforward to backport.

So I think updating rust-matchers and rust-tracing-subscriber together is the best option to ship this security update. rust-tracing-subscriber is the only package in both Fedora and EPEL that depends on rust-matchers, so no other packages would be impacted.

I'll be preparing the update for Fedora, EPEL 9, and EPEL 10.2 for now, and will wait on your input regarding what to do in EPEL 10.1 and 10.0 branches.

Update: I've now prepared the updates and did a full check for impacted applications, and the affected packages in EPEL 10.x are only

  • epel10.1: maturin, ruff
  • epel10.0: maturin

Metadata Update from @carlwgeorge:
- Issue tagged with: meeting

We discussed this today at the EPEL Steering Committee meeting.

We are broadly supportive of this, but it would still fall under the Incompatible Upgrades policy. This would count for step 3, but would still need step 1 of a post on epel-devel. After it's been open for discussion on the list for a week we can officially vote on it.

I checked and that CVE is rated as follows:

Given the low ratings so far, I lean towards only doing this in epel10 (10.2), and leaving epel10.0 and epel10.1 alone. In the meeting a few people mentioned they would lean towards also doing epel10.1, so we don't quite have consensus on this. We didn't really discuss epel9, but I suspect opinions would vary there as well. We'll likely just do a separate votes for each branch.

Just to clarify - for EPEL 9 and 10.2, pushing this update is covered by the existing exception, as was discussed in #316 - which is why I already pushed the updates there. This ticket is exclusively about EPEL 10.1 and 10.0, which isn't covered by the existing policy / exceptions.

If there is consensus that the "security issue" is low priority enough to not bother touching 10.1 and 10.0, then I'm fine with that.

Ah, sorry for the oversight, you are correct. EPEL 9 and 10.2 are covered by the previously approved exception. I personally don't think it's worth bring this to EPEL 10.0 and 10.1 due to the low rating, but that's just my opinion and doesn't necessarily represent a consensus. Re-reading the meeting log, no one explicitly expressed support for 10.0, and on 10.1 @tdawson said he thought it could go either way. Regardless, if you still want to pursue those branches it would require the incompat process steps.

We touched on this again at the meeting today. You can pursue making this change in 10.0 and 10.1 via the full incompat process if you want, but unless something significant changes (such as the rating getting upgraded) it sounds like most (if not all) of the Steering Committee members would vote -1 on it.

Metadata Update from @carlwgeorge:
- Issue close_status updated to: Deferred
- Issue status updated to: Closed (was: Open)

Thank you for your input. I agree with the assessment that with the severity of the issue being so low (and both affected packages basically only ever running against "trusted input", it's not really worth it going through the "incompatible changes" process for this.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/348

Please continue any further discussion there.
Metadata
None

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.