-
-
Notifications
You must be signed in to change notification settings - Fork 285
Proposal: SBOM Validation should not hard code expected values #4418
Copy link
Copy link
Open
Labels
ansibleIssues related to our ansible playbooks in the infrastructure repoIssues related to our ansible playbooks in the infrastructure repoenhancementIssues that enhance the code or documentation of the repo in any wayIssues that enhance the code or documentation of the repo in any wayjenkinsIssues that enhance or fix our jenkins serverIssues that enhance or fix our jenkins servertestingIssues that enhance or fix our test suitesIssues that enhance or fix our test suites
Description
Metadata
Metadata
Assignees
Labels
ansibleIssues related to our ansible playbooks in the infrastructure repoIssues related to our ansible playbooks in the infrastructure repoenhancementIssues that enhance the code or documentation of the repo in any wayIssues that enhance the code or documentation of the repo in any wayjenkinsIssues that enhance or fix our jenkins serverIssues that enhance or fix our jenkins servertestingIssues that enhance or fix our test suitesIssues that enhance or fix our test suites
Type
Fields
Give feedbackNo fields configured for issues without a type.
Projects
StatusShow more project fields
Todo
Problem
During the Temurin build process, we use the jenkins job sbom_validator_job to validate the sbom.
Part of this includes a set of hard-coded values it expects to find in a valid sbom file (freetype version, gcc version, etc).
Sometimes one of those values is changed upstream, e.g:
When that happens, all builds will fail validation until the validator code is manually fixed.
Proposed Solution
The validation script should retrieve all values from where they are set (playbook, source code, etc)
There should be no hard-coded version strings in this file.
Example
We could get the version of freetype we expect in the sbom by getting the latest commit to freetype.h in the jdk source repository.