rebuild packages with cxx v1.0.195+ to address RUSTSEC-2026-0202

decathorpe commented

2026-07-14 21:58:02 +00:00

Owner

There is a recently published RUSTSEC advisory for the cxx crate:
https://rustsec.org/advisories/RUSTSEC-2026-0202.html

I am builing v1.0.197 for all Fedora and EPEL branches now, but applications would need to be rebuilt to pick up the fix for this issue.

For Rawhide / F45+, the mass rebuild will take care of the rebuild. It is unclear to me whether this issue is significant enough to warrant rebuilding affected applications in stable branches too (potentially affected - I have not checked whether they use the affected API):

akonadi-search
angelfish
cxx-rust-cssparser
ddnet
dnsdist
gn
mir
newsboat
pdns-recursor

There is a recently published RUSTSEC advisory for the cxx crate: https://rustsec.org/advisories/RUSTSEC-2026-0202.html I am builing v1.0.197 for all Fedora and EPEL branches now, but applications would need to be rebuilt to pick up the fix for this issue. For Rawhide / F45+, the mass rebuild will take care of the rebuild. It is unclear to me whether this issue is significant enough to warrant rebuilding affected applications in stable branches too (potentially affected - I have not checked whether they use the affected API): - [ ] akonadi-search - [ ] angelfish - [ ] cxx-rust-cssparser - [ ] ddnet - [ ] dnsdist - [x] gn - [ ] mir - [ ] newsboat - [x] pdns-recursor

decathorpe added the

rebuild

label

2026-07-14 21:58:02 +00:00

music commented

2026-07-15 08:45:17 +00:00

Member

For now, gn still doesn’t compile any Rust code, and uses only a C++ header from the cxx crate, so it will not be affected.

For now, `gn` still doesn’t compile any Rust code, and uses only a C++ header from the `cxx` crate, so it will not be affected.

👍 1

music commented

2026-08-24 07:14:19 +00:00

Member

It’s hard to evaluate what might actually be used from a typical application, since usage can be so indirect and implicit. For example, the sole explicit use of cxx in cxx-rust-cxxparser is:

#[cxx::bridge(namespace = "cssparser::rust")]

None of these applications is co-maintained by rust-sig, so we can’t rebuild them without invoking provenpackager privilege, which generally ought to require some effort to coordinate with maintainers and get consent or at least notify them in advance.

Maybe the best thing to do in a case like this would just be to file bugs against the applications, linking this issue and/or the RUSTSEC advisory, and saying: this package uses the cxx crate, but we aren’t sure if it uses the affected API. If it’s affected by the issue, you can fix it by simply rebuilding it. Kind of like the prodsec security bugs, but more carefully targeted and helpful.

Some packages were rebuilt recently enough to have used the fixed cxx crate in some branches. Only one was rebuilt in all potentially-affected branches.

akonadi-search was rebuilt recently enough in F44+ and EPEL10, but not F43
angelfish was rebuilt recently enough in F44+, but not F43 nor EPEL10
cxx-rust-cxxparser was not rebuilt recently enough anywhere
ddnet was rebuilt recently enough in F45+, but not F44 nor F43; the update was still in testing
dnsdist was rebuilt recently enough in F45+, but not F44, F43, EPEL10, nor EPEL9
mir was not rebuilt recently enough anywhere
newsboat was not rebuilt recently enough anywhere
pdns-recursor was rebuilt recently enough in all Fedora branches and in EPEL10 (including 10.2). It was not rebuilt recently enough in EPEL9, but the older 4.x version packaged there does not use the cxx crate.

It’s hard to evaluate what might actually be used from a typical application, since usage can be so indirect and implicit. For example, the sole explicit use of `cxx` in `cxx-rust-cxxparser` is: ``` #[cxx::bridge(namespace = "cssparser::rust")] ``` None of these applications is co-maintained by `rust-sig`, so we can’t rebuild them without invoking provenpackager privilege, which generally ought to require some effort to coordinate with maintainers and get consent or at least notify them in advance. Maybe the best thing to do in a case like this would just be to file bugs against the applications, linking this issue and/or the RUSTSEC advisory, and saying: this package uses the cxx crate, but we aren’t sure if it uses the affected API. If it’s affected by the issue, you can fix it by simply rebuilding it. Kind of like the prodsec security bugs, but more carefully targeted and helpful. Some packages were rebuilt recently enough to have used the fixed `cxx` crate in some branches. Only one was rebuilt in *all* potentially-affected branches. - akonadi-search was rebuilt recently enough in F44+ and EPEL10, but not F43 - angelfish was rebuilt recently enough in F44+, but not F43 nor EPEL10 - cxx-rust-cxxparser was not rebuilt recently enough anywhere - ddnet was rebuilt recently enough in F45+, but not F44 nor F43; the update was still in testing - dnsdist was rebuilt recently enough in F45+, but not F44, F43, EPEL10, nor EPEL9 - mir was not rebuilt recently enough anywhere - newsboat was not rebuilt recently enough anywhere - pdns-recursor was rebuilt recently enough in all Fedora branches and in EPEL10 (including 10.2). It was not rebuilt recently enough in EPEL9, but the older 4.x version packaged there does not use the `cxx` crate.

music commented

2026-08-24 07:16:13 +00:00

Member

Hmm, in the above comment I was only considering Bodhi updates to decide what was rebuilt recently enough. If I claimed a package was not rebuilt in F45+, it was probably actually rebuilt in the F45 mass rebuild, which doesn’t produce a Bodhi update.

Rows
Columns

rebuild packages with cxx v1.0.195+ to address RUSTSEC-2026-0202 #36