From efb88d1d527c8e419af9ab8300e9e9345b29284c Mon Sep 17 00:00:00 2001 From: Laura Barcziova Date: Thu, 20 Aug 2026 11:26:06 +0200 Subject: [PATCH] Enforce fixVersion validation when searching for rebuild dependencies The triage and sibling rebuild agents search for dependency CVE trackers by CVE ID and component, but never validated that the found tracker targets the same RHEL version stream. With multiple z-streams now active (10.0.z, 10.1.z, 10.2.z, 10.3), the LLM could pick a tracker from a different stream, causing the buildroot check to use the wrong NVR and produce nonsensical postpone messages (e.g. "waiting for golang (golang-1.26.5-1.el10_0)" on a rhel-10.3 ticket). Changes: - Instruct triage agent to validate that dependency issues have a matching fixVersion (same major.minor) and never use trackers from different streams - Add rebase/update ticket fallback when no CVE tracker exists for the target stream (with requirement to verify the rebase fixes the CVE) - Fall back to clarification-needed instead of using a wrong-stream tracker - Apply same fixVersion validation to sibling rebuild analysis Assisted-by: Claude Opus 4.6 --- ruff.toml | 2 ++ ymir/agents/prompts/triage/prompt.j2 | 23 +++++++++++++++++++++-- ymir/agents/rebuild_consolidation.py | 16 ++++++++++++++-- 3 files changed, 37 insertions(+), 4 deletions(-) diff --git a/ruff.toml b/ruff.toml index d3f288e91..a419cf170 100644 --- a/ruff.toml +++ b/ruff.toml @@ -35,4 +35,6 @@ ignore = [ "**/tests/**" = ["S101", "S105", "S106", "S107", "S108", "S603", "S607"] # Helper scripts shell out to known binaries by name. "scripts/**" = ["S603", "S607"] +# LLM prompt strings contain JQL (SQL-like syntax) but are not SQL queries +"ymir/agents/rebuild_consolidation.py" = ["S608"] "agents_as_skills/install-skills.py" = ["S603", "S607"] diff --git a/ymir/agents/prompts/triage/prompt.j2 b/ymir/agents/prompts/triage/prompt.j2 index 9ca9e00f2..cbb414911 100644 --- a/ymir/agents/prompts/triage/prompt.j2 +++ b/ymir/agents/prompts/triage/prompt.j2 @@ -356,8 +356,14 @@ You must decide between one of the following actions. Follow these guidelines to * If no linked issue found, use search_jira_issues to find it. Try JQL queries like: - project = RHEL AND summary ~ "" AND component != "" Include fields ["key", "summary", "fixVersions", "status"] in the search - * Once found, call get_jira_details on the dependency issue and thoroughly - verify it was actually fixed: + * **CRITICAL — fixVersion validation**: The dependency issue MUST target the same + RHEL version stream as this issue (same major.minor, e.g. both rhel-10.3 or + rhel-10.3.z). If the search returns multiple results, select only the one + whose fixVersion matches this issue's stream. NEVER use a dependency tracker + from a different stream (e.g. do not use a rhel-10.0.z tracker for a + rhel-10.3 issue — that is a completely different release). + * Once found (with matching fixVersion), call get_jira_details on the dependency + issue and thoroughly verify it was actually fixed: - Check if 'Fixed in Build' field is set (non-null/non-empty) - Check the issue status and resolution — if the dependency issue was Closed/Done with resolution like 'NOTABUG', 'WONTFIX', 'DUPLICATE', @@ -374,6 +380,19 @@ You must decide between one of the following actions. Follow these guidelines to and set pending_issues to the dependency issue key. Also set package, fix_version, cve_id, dependency_issue, and dependency_component (same values as you would for a rebuild resolution). + * **Fallback — no matching CVE tracker found**: If no dependency CVE tracker + exists for this version stream, search for a rebase/update ticket on the + dependency component that may include the CVE fix (e.g. a golang rebase + that bumps to a version containing the fix). Use JQL like: + - project = RHEL AND component = "" AND (summary ~ "rebase" OR summary ~ "update") AND fixVersion in ("", ".z") + If a rebase ticket is found, verify with certainty that the rebase target + version actually includes the fix for this CVE (check upstream release + notes or changelogs). Only use the rebase ticket as the dependency_issue + if you are 100% sure it resolves the CVE. + * If you cannot find any dependency ticket for the correct version stream, + or you are not certain that a found ticket resolves the CVE, use + "clarification-needed" resolution — do NOT fall back to using a tracker + from a different version stream. 3.3. You must provide a clear justification explaining why a rebuild is needed and how it addresses the issue. 3.4. If rebuild: set Jira fields as per the instructions below. diff --git a/ymir/agents/rebuild_consolidation.py b/ymir/agents/rebuild_consolidation.py index 263bdc272..8855f4561 100644 --- a/ymir/agents/rebuild_consolidation.py +++ b/ymir/agents/rebuild_consolidation.py @@ -272,8 +272,20 @@ def _build_sibling_analysis_prompt( the summary and use search_jira_issues with JQL: project = RHEL AND summary ~ "" \ AND component != "{package}" - 4. Once you find the dependency issue, use get_jira_details - on it and thoroughly verify it was actually fixed: + - CRITICAL: The dependency issue MUST have the same + fixVersion stream as {candidate_key} (same major.minor). + If multiple results are returned, pick only the one + matching the same stream. Never use a tracker from a + different stream (e.g. rhel-10.0.z for a rhel-10.3 issue). + - If no matching CVE tracker found, look for a rebase/update + ticket on the dependency component with a matching + fixVersion that includes the CVE fix. Only use it if you + are certain the rebase resolves the CVE. + - If no dependency ticket can be found for the correct + stream, set is_dependency_rebuild=false. + 4. Once you find the dependency issue (with matching fixVersion), + use get_jira_details on it and thoroughly verify it was + actually fixed: - Check if 'Fixed in Build' field is set (non-null/non-empty) - Check the issue status and resolution — if the dependency issue was Closed/Done with resolution like 'NOTABUG',