Skip to content
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

Merged
merged 3 commits into from
Sep 18, 2024

Conversation

simonbaird
Copy link
Member

@simonbaird simonbaird commented Sep 11, 2024

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

@codecov-commenter
Copy link

codecov-commenter commented Sep 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (b445a4f) to head (7ccc545).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##              main     #1135    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          115       117     +2     
  Lines         5894      6010   +116     
==========================================
+ Hits          5894      6010   +116     
Files with missing lines Coverage Δ
policy/lib/set_helpers.rego 100.00% <100.00%> (ø)
policy/lib/set_helpers_test.rego 100.00% <100.00%> (ø)
policy/release/rpm_repos.rego 100.00% <100.00%> (ø)
policy/release/rpm_repos_test.rego 100.00% <100.00%> (ø)

@simonbaird simonbaird force-pushed the repoid-checks branch 4 times, most recently from 35a11a7 to 4e28682 Compare September 11, 2024 22:10
@simonbaird
Copy link
Member Author

I might tinker with the annotations a little more, but I think it's ready for review.

@simonbaird simonbaird marked this pull request as ready for review September 11, 2024 22:11
Copy link
Member

@zregvart zregvart left a 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...

policy/release/repo_ids.rego Outdated Show resolved Hide resolved
policy/release/repo_ids.rego Outdated Show resolved Hide resolved
@simonbaird
Copy link
Member Author

I'll make a few changes. Moving to draft for a bit.

@simonbaird simonbaird marked this pull request as draft September 13, 2024 16:22
# Checks that all RPMs listed in the SBOM have a valid and known
# repository id.
#
package policy.release.repo_ids
Copy link
Member

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.

Copy link
Member Author

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.

# description: >-
# A list of valid and known repository ids should be available in the data.
# custom:
# short_name: rpm_repo_ids_list_provided
Copy link
Member

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.

Copy link
Member Author

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 Show resolved Hide resolved
policy/release/repo_ids.rego Outdated Show resolved Hide resolved
# 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,
Copy link
Member

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.

Copy link
Member Author

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 Show resolved Hide resolved
import data.lib

# METADATA
# title: Known repo id list provided
Copy link
Member

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.

Copy link
Member Author

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 Show resolved Hide resolved
policy/release/repo_ids.rego Outdated Show resolved Hide resolved
}

# Avoid including thousands of bad purls in the violation reason
max_bad_purls := 10
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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. 😁

Copy link
Member

Choose a reason for hiding this comment

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

Fair point.

@simonbaird
Copy link
Member Author

Still draft, but nearly there.

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.)
@simonbaird
Copy link
Member Author

The latest version has a different way of limiting the number of violations, as discussed post standup today.

@simonbaird simonbaird marked this pull request as ready for review September 17, 2024 18:07
@simonbaird
Copy link
Member Author

Moved out of draft.

@simonbaird simonbaird force-pushed the repoid-checks branch 2 times, most recently from 10574f9 to 7e78f51 Compare September 17, 2024 21:47
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
@simonbaird
Copy link
Member Author

simonbaird commented Sep 17, 2024

Things not in this PR:

  • Adding the new rule to the 'redhat' collection. I'm planning to do that later while adding an effective_on date in the future.
  • Using the 'item' (correction 'term') mechanism to be able to create fine grained exclude directives. This is a good idea, but I think it can be done in a new PR and in a new story.

Copy link
Member

@zregvart zregvart left a 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

@simonbaird simonbaird merged commit 0c4f17b into enterprise-contract:main Sep 18, 2024
4 checks passed
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.

4 participants