fix(yara): modified Source0 with malware-scanner-tripping fixture stripped#17097
Open
PawelWMS wants to merge 1 commit into
Open
fix(yara): modified Source0 with malware-scanner-tripping fixture stripped#17097PawelWMS wants to merge 1 commit into
PawelWMS wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adjusts the yara component to use a repacked upstream Source0 tarball with a benign OSS-Fuzz fixture removed, avoiding false-positive malware detection during the signing pipeline while keeping the spec’s Source0 filename stable.
Changes:
- Add a dedicated
yara.comp.tomlthat removes the upstreamsourcesfile and replacesSource0viasource-filespointing at a modified-tarball blob URL. - Update rendered
yaraspec metadata (release bump + changelog) and thesourcesSHA512 to match the modified tarball. - Add a helper script (
modify_source.sh) to deterministically repack the upstream tarball with the flagged fixture stripped.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| specs/y/yara/yara.spec | Release bump and changelog entry reflecting the modified Source0 artifact. |
| specs/y/yara/sources | Updates SHA512 for yara-4.5.4.tar.gz to the modified tarball hash. |
| locks/yara.lock | Refreshes input fingerprint to reflect the new component configuration/source. |
| base/comps/yara/yara.comp.toml | Introduces component customization: drop upstream sources and define source-files to fetch the modified tarball. |
| base/comps/yara/modify_source.sh | Adds deterministic repack script to strip the malware-scanner-tripping fixture and output the required SHA512. |
| base/comps/components.toml | Removes yara from the inline unmodified-component list now that it has a dedicated .comp.toml. |
PawelWMS
commented
May 8, 2026
49c1d00 to
9a74ccb
Compare
christopherco
requested changes
May 12, 2026
Collaborator
christopherco
left a comment
There was a problem hiding this comment.
Needs commits to be squashed and render CI failure to be addressed
a276c3b to
8cf89b0
Compare
The upstream `yara-4.5.4.tar.gz` tarball ships four files that the
automated package-signing pipeline's malware scanner rejects:
* `tests/oss-fuzz/dotnet_fuzzer_corpus/obfuscated` -- a deliberately
obfuscated .NET binary used as an oss-fuzz seed-corpus input for
YARA's .NET parser fuzzer; matches generic .NET-obfuscator
detection heuristics by design.
* `tests/data/05cd06e6a2...e8971efded0650`
* `tests/data/079a472d22...58ce2d3b885` (and its `.upx`-packed sibling)
* `tests/data/e3d45a2865...86bc129f27345`
The three SHA-256-named fixtures under `tests/data/` are real PE
malware samples that the upstream YARA project ships to test the
YARA PE-format parser (one is UPX-packed). They are benign by
intent -- they are test inputs, not runtime artefacts -- but the
SRPM payload contains them verbatim, which is what the malware
scanner inspects.
Mechanism
---------
* `base/comps/yara/modify_source.sh` is a deterministic strip-and-
repack script that downloads the upstream tarball, removes the
four flagged files, edits `Makefile.am` to drop `test-pe` from
the autotools `check_PROGRAMS` list AND its now-orphan
`test_pe_SOURCES` / `test_pe_LDADD` / `test_pe_LDFLAGS` variable
declarations (`automake` runs with `-Werror`, so orphan-variable
warnings would fail `autoreconf` at %prep time), and repacks
deterministically with
`tar --sort=name --mtime=... --owner=0 --group=0 --numeric-owner
| gzip -n -9`. The script writes its outputs to
`base/build/work/scratch/yara/` (covered by the repo's
top-level .gitignore via `build/`) and prints a ready-to-paste
`az storage blob upload` command for the upload step.
* `base/comps/yara/yara.comp.toml` adds a
`[[components.yara.source-files]]` entry pointing at the
repacked tarball in the lookaside `repo` container under the
`pkgs_modified/` prefix. It uses the `replace-upstream = true`
/ `replace-reason = "..."` mechanism to swap the same-named
upstream entry in the Fedora `sources` manifest in place; no
`file-remove`-on-`sources` overlay is needed.
* The spec's `Source0:` line and filename are unchanged; the
upstream filename `yara-4.5.4.tar.gz` is preserved so no spec
overlay is required to point at a different basename.
Trade-offs
----------
* Build-time loss: the upstream `test-pe` test program no longer
runs as part of `%check`. The runtime PE rule-scanning code path
-- the same one consumers exercise via the `yara` CLI -- is
unaffected; this only loses upstream's own build-time regression
coverage for the PE parser. yara's other test programs
(`test-rules`, `test-elf`, `test-dotnet`, `test-macho`, etc.)
continue to run normally.
* `test-pe.c` stays in the tarball (it's still compiled as part of
`check_PROGRAMS`'s implicit compile rules until the next
autotools regen), but the autoreconf'd `Makefile.in` no longer
lists `test-pe` in `TESTS`, so the autotools test driver never
invokes it. Harmless, unused.
Validation
----------
* Render: clean. `specs/y/yara/sources` carries the
modified-tarball SHA512 on a single line.
* Lock: `locks/yara.lock` refreshed deterministically.
* `autoreconf --force --install` against the repacked tarball
succeeds with zero `test_pe_*` warnings (same step that failed
in the previous Koji build).
* Repack determinism: re-running `modify_source.sh` against the
same upstream tarball yields a byte-identical output (sorted
file order, fixed mtime, owner=group=0, numeric-owner,
`gzip -n -9`), so the SHA512 in this commit is reproducible by
anyone with the same upstream input.
8cf89b0 to
e747649
Compare
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.
Koji build.
Fixes AB#19872
The upstream
yara-4.5.4.tar.gztarball ships four files that theautomated package-signing pipeline's malware scanner rejects:
tests/oss-fuzz/dotnet_fuzzer_corpus/obfuscated-- a deliberatelyobfuscated .NET binary used as an oss-fuzz seed-corpus input for
YARA's .NET parser fuzzer; matches generic .NET-obfuscator
detection heuristics by design.
tests/data/05cd06e6a2...e8971efded0650tests/data/079a472d22...58ce2d3b885(and its.upx-packed sibling)tests/data/e3d45a2865...86bc129f27345The three SHA-256-named fixtures under
tests/data/are real PEmalware samples that the upstream YARA project ships to test the
YARA PE-format parser (one is UPX-packed). They are benign by
intent -- they are test inputs, not runtime artefacts -- but the
SRPM payload contains them verbatim, which is what the malware
scanner inspects.
Mechanism
base/comps/yara/modify_source.shis a deterministic strip-and-repack script that downloads the upstream tarball, removes the
four flagged files, edits
Makefile.amto droptest-pefromthe autotools
check_PROGRAMSlist AND its now-orphantest_pe_SOURCES/test_pe_LDADD/test_pe_LDFLAGSvariabledeclarations (
automakeruns with-Werror, so orphan-variablewarnings would fail
autoreconfat %prep time), and repacksdeterministically with
tar --sort=name --mtime=... --owner=0 --group=0 --numeric-owner | gzip -n -9. The script writes its outputs tobase/build/work/scratch/yara/(covered by the repo'stop-level .gitignore via
build/) and prints a ready-to-pasteaz storage blob uploadcommand for the upload step.base/comps/yara/yara.comp.tomladds a[[components.yara.source-files]]entry pointing at therepacked tarball in the lookaside
repocontainer under thepkgs_modified/prefix. It uses thereplace-upstream = true/
replace-reason = "..."mechanism to swap the same-namedupstream entry in the Fedora
sourcesmanifest in place; nofile-remove-on-sourcesoverlay is needed.The spec's
Source0:line and filename are unchanged; theupstream filename
yara-4.5.4.tar.gzis preserved so no specoverlay is required to point at a different basename.
Trade-offs
Build-time loss: the upstream
test-petest program no longerruns as part of
%check. The runtime PE rule-scanning code path-- the same one consumers exercise via the
yaraCLI -- isunaffected; this only loses upstream's own build-time regression
coverage for the PE parser. yara's other test programs
(
test-rules,test-elf,test-dotnet,test-macho, etc.)continue to run normally.
test-pe.cstays in the tarball (it's still compiled as part ofcheck_PROGRAMS's implicit compile rules until the nextautotools regen), but the autoreconf'd
Makefile.inno longerlists
test-peinTESTS, so the autotools test driver neverinvokes it. Harmless, unused.
Validation
specs/y/yara/sourcescarries themodified-tarball SHA512 on a single line.
locks/yara.lockrefreshed deterministically.autoreconf --force --installagainst the repacked tarballsucceeds with zero
test_pe_*warnings (same step that failedin the previous Koji build).
modify_source.shagainst thesame upstream tarball yields a byte-identical output (sorted
file order, fixed mtime, owner=group=0, numeric-owner,
gzip -n -9), so the SHA512 in this commit is reproducible byanyone with the same upstream input.