-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confirm all rpms in sboms have a known repo id #1135
Confirm all rpms in sboms have a known repo id #1135
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1135 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 115 117 +2
Lines 5894 6010 +116
==========================================
+ Hits 5894 6010 +116
|
35a11a7
to
4e28682
Compare
I might tinker with the annotations a little more, but I think it's ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, one test case that could be added is for checking that the list appears in the error message, in addition to testing truncated_list_to_string
, but that's just nitpicking...
I'll make a few changes. Moving to draft for a bit. |
policy/release/repo_ids.rego
Outdated
# Checks that all RPMs listed in the SBOM have a valid and known | ||
# repository id. | ||
# | ||
package policy.release.repo_ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be rpm_repo_ids
since the repository
terminology is very ambiguous.
Also not sure if ids
need to be in the name. I can imagine this package doing something with rpm repos which is not necessarily related to their ids.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revised in latest version. See if you like it.
policy/release/repo_ids.rego
Outdated
# description: >- | ||
# A list of valid and known repository ids should be available in the data. | ||
# custom: | ||
# short_name: rpm_repo_ids_list_provided |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The juxtaposition of package name and short name make this repetitive, repo_ids.rpm_repo_ids_list_provided
. With my previous comment in mind, consider something like this rpm_repo.known_ids_list_provided
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed I think.
policy/release/repo_ids.rego
Outdated
# solution: >- | ||
# Ensure every rpm is from a known and accepted repository and that the data in the SBOM | ||
# correctly records that. | ||
# # Todo: Until the sbom generation is upated, this will always fail, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should enable this when that change is released and there's a new Task users can upgrade to. Let's use effective_on
to give users ~30 days to make the upgrade.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do in a future PR.
policy/release/repo_ids.rego
Outdated
import data.lib | ||
|
||
# METADATA | ||
# title: Known repo id list provided |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can probably be merged with rpm_repo_ids_valid
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still open to persuasion, but I think I preferred them separate.
policy/release/repo_ids.rego
Outdated
} | ||
|
||
# Avoid including thousands of bad purls in the violation reason | ||
max_bad_purls := 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems oddly specific. Let all the failures show up so users can tackle them as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you worried about showing (say) 5000 violations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because every purl is malformed? That seems like a bigger problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking is: if you do have this problem, it's better if we don't add a 9000 screen EC task log on top of problem pile. 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point.
4e28682
to
cd28756
Compare
Still draft, but nearly there. |
cd28756
to
883f4e7
Compare
The one exception is coverage, since the coverage numbers only make sence if you run all the tests. I also changed the ordering of targets for the sake of tidiness. Quality-of-life tweak while doing some TDD for... Ref: https://issues.redhat.com/browse/EC-742
I want to use this in the next commit. (As mentioned in the comments, I think it can make some code a little more readable in some cases.)
883f4e7
to
ed2aef0
Compare
The latest version has a different way of limiting the number of violations, as discussed post standup today. |
Moved out of draft. |
10574f9
to
7e78f51
Compare
For all components in all sboms that are rpms, require they have a repository_id value in their purl, and require that the repository_id value is in in the big list of known repository_ids. Includes a bit of extra work to limit the number of violations produced, since I'm expecting there to be either none of many hundreds. As mentioned in a Todo in the comments, this is not yet added to the redhat collection, but it will be added soon in an upcoming PR. Ref: https://issues.redhat.com/browse/EC-848
7e78f51
to
7ccc545
Compare
Things not in this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would have loved to have seen term on a per package basis, but this is okay for now and that can be added in a followup
Note that we can't enable this now, since the sboms that Konflux creates don't yet have repo ids, so I didn't add the one relevant check to the
redhat
collection in this PR.Ref: EC-848