Skip to content

Fix TC-5274: Show fix patterns for all affected files - #352

Open
TamarW0 wants to merge 6 commits into
mainfrom
worktree-tc-5274
Open

TamarW0 wants to merge 6 commits into
mainfrom
worktree-tc-5274

Conversation

@TamarW0

@TamarW0 TamarW0 commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

Fixes inconsistency where affected files section showed test files but fix patterns section did not.

Applied consistent filtering to both sections - now both show only C/C++ source code files, excluding test files and build configuration.

For RPM scan workflow only (C/C++ packages)

Fixes: TC-5274

Tamar Weisskopf and others added 4 commits September 9, 2026 14:48
Problem:
When scanning an RPM with a CVE affecting multiple files (e.g., openssl
with 3 affected files: .c, .t, .eml), only the first C source file showed
fix patterns. Test files and other formats were completely hidden from the
report even though they had valid fixes.

Root Cause:
The _filter_review_snippets() function in cve_checker_report.py was too
aggressive, filtering out:
1. Any file with /test/ in the path
2. Any file not ending in .c/.h/.cpp extensions

This meant test files (.t) and data files (.eml) were excluded entirely,
even when they were legitimately affected by the CVE and had fix patterns.

Solution:
1. Modified _filter_review_snippets() to only exclude build-system files
   (CMakeLists.txt, Makefile, .cmake, .mk) while preserving all source
   files including tests and non-C/C++ files.

2. Improved _extract_snippets_from_patch() in code_agent_graph_defs.py to
   ensure one snippet per affected file is extracted first before adding
   additional snippets from files with multiple hunks. This prevents a
   single file with many changes from consuming all snippet slots.

Impact:
Users will now see fix patterns for ALL affected files regardless of file
type (C, Perl, email, Python, etc.), making it clear what was actually
fixed in each file.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…terns

Co-Authored-By: Tamar Weisskopf <tweissko@redhat.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…rce only

Applied consistent filtering to show only primary C/C++ source code files,
excluding test files and build configuration from both sections.

Co-Authored-By: Tamar Weisskopf <tweissko@redhat.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Tests the _is_source_code_file and _filter_to_source_code_files functions
with the actual TC-5274 example case.

Co-Authored-By: Tamar Weisskopf <tweissko@redhat.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@TamarW0
TamarW0 marked this pull request as ready for review September 14, 2026 11:03
@TamarW0
TamarW0 requested a review from tmihalac September 14, 2026 20:51

@tmihalac tmihalac left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Review — TC-5274

Nice cleanup: extracting the predicate into _is_source_code_file / _filter_to_source_code_files and applying it to both affected_files and review snippets removes the duplication and fixes the reported inconsistency. Snippet-filter behavior is preserved exactly, and the empty-result fallback is a sensible guard. A couple of things worth addressing below.

Important

  • /test/ exclusion misses top-level test/ directories, and the test gives false confidence. The "/test/" in file_path check requires a leading slash, so a top-level test/foo.c (exactly how OpenSSL lays out its C test suite) is not matched, ends with .c, and is classified as source. The added assertion _is_source_code_file("test/recipes/80-test_cms.t") is False passes only because .t isn't a source extension — the /test/ branch is never actually exercised. A path like test/bad_dtls_frag.c would slip through. Consider file_path.startswith("test/") or "/test/" in file_path, plus a test with a top-level test/*.c path. (See inline comment.)

Suggestions

  • Test coverage gaps: no cases for CMakeLists/Makefile exclusion, .cpp/.cc/.cxx extensions, a top-level test/*.c file, or the empty-result fallback (_filter_to_source_code_files returning the original list). The fallback is behaviorally important — if it regresses, reports could silently go empty — yet it's untested. Prefer plain assert-based pytest style over the trailing print(...), and avoid the sys.path.insert mutation (it leaks into other tests) if a normal import / conftest.py can be used.

if "CMakeLists" in file_path or "Makefile" in file_path:
return False

if "/test/" in file_path:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"/test/" in file_path requires a leading slash, so a top-level test/*.c (e.g. OpenSSL's test/foo.c) is not excluded — it ends with .c and is treated as source, contradicting the "excluding test files" intent. Suggest if file_path.startswith("test/") or "/test/" in file_path: and add a test covering a top-level test/*.c path (the current .t assertion passes on extension, not on this branch).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants