feat(RHEL): handle multiple fix streams#1232
Draft
willmurphyscode wants to merge 1 commit into
Draft
Conversation
Previously, when there were multiple RHSAs that fixed the same RPM for the same RHEL major version, Vunnel would either collapse them into a complex boolean expression if possible (for example if upstream moved and EVR was enough to distinguish the versions) or else would collapse to the higher version to prevent false negatives. Instead, emit an additional item in the JSON for each additional relevant advisory. Crucially, the highest EVR is still in the "version" field so that legacy consumers of the data won't know the change, but these additional advisories will enable new consumers to decide which RHSA is most applicable to their stream. Note that this makes the 'elN_M' suffixes on RPM versions somewhat load bearing, since that is how stream information is reported through, but that convention seems very strong and well-established. Signed-off-by: Will Murphy <willmurphyscode@users.noreply.github.com>
willmurphyscode
commented
Jun 25, 2026
| "Description": "An untrusted library search path flaw was found in the JCE component of OpenJDK. A local attacker could possibly use this flaw to cause a Java application using JCE to load an attacker-controlled library and hence escalate their privileges.", | ||
| "FixedIn": [ | ||
| { | ||
| "AdditionalAdvisoryFixes": [ |
Contributor
Author
There was a problem hiding this comment.
What populate additional if there's only the one?
willmurphyscode
commented
Jun 25, 2026
| # the canonical CVE-2024-8088 shape (already deduped + sorted ascending by base) | ||
| fixes = [_ar("0:3.9.18-3.el9_4.5"), _ar("0:3.9.19-8.el9")] | ||
| assert _build_vulnerable_range(fixes) == "< 0:3.9.18-3.el9_4.5 || >= 0:3.9.19, < 0:3.9.19-8.el9" | ||
| class TestSameBaseAdditionalAdvisoryFixes: |
Contributor
Author
There was a problem hiding this comment.
Make sure this has real data behind it - choose real examples.
willmurphyscode
commented
Jun 25, 2026
| "ID": "RHSA-2023:2260", | ||
| "Link": "https://access.redhat.com/errata/RHSA-2023:2260" | ||
| }, | ||
| "Version": "0:1.18.4-6.el9" |
Contributor
Author
There was a problem hiding this comment.
Can the vunnel side bucket these into RHEL minor versions ahead of time? Like just capturing the raw field in here and then letting grype bucket by it later maybe it should be a separate field.
Contributor
Author
There was a problem hiding this comment.
Something something package qualifiers.
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
1 participant
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.
Previously, when there were multiple RHSAs that fixed the same RPM for the same RHEL major version, Vunnel would either collapse them into a complex boolean expression if possible (for example if upstream moved and EVR was enough to distinguish the versions) or else would collapse to the higher version to prevent false negatives.
Instead, emit an additional item in the JSON for each additional relevant advisory. Crucially, the highest EVR is still in the "version" field so that legacy consumers of the data won't know the change, but these additional advisories will enable new consumers to decide which RHSA is most applicable to their stream.
Note that this makes the 'elN_M' suffixes on RPM versions somewhat load bearing, since that is how stream information is reported through, but that convention seems very strong and well-established.