-
Notifications
You must be signed in to change notification settings - Fork 587
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
fix: apk product/vendor generation for old metadata #1635
Conversation
This fixes some instances where the improved APK CPE generation logic caused regressions for older alpine package APK metadata. It now generates multiple "upstream" candidates with both name and package type which reduces the amount of duplicated code in the apk cpe gen logic. This also improves the handling of stream version packages, so now we can correctly identify packages such as ruby3.2-rexml as the rexml ruby gem. Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
Benchmark Test ResultsBenchmark results from the latest changes vs base branch
|
Type Type | ||
} | ||
|
||
func (m ApkMetadata) UpstreamCandidates() (candidates []UpstreamCandidate) { |
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 is more of a preference than anything else -- since UpstreamCandidates
(and the former Upstream
) is only used for the benefit of CPE generation the more ideal spot is where CPE generation is being done, in syft/pkg/cataloger/common/cpe
. This also has the benefit of being unexported so it can't be used in the API.
What are your thoughts about this?
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.
Yeah, I would have liked that; however, it's also needed for the purl.
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.
Hmm, I guess I could move it under syft/pkg/cataloger/common/cpe
and then import it in apkdb?
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 still have to be exported though, right?
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 missed the usage in purl processing. I take back my comment then. I think in the future this will be in a better position to refactor: later we'll be moving the CPE generation logic back to where packages are created (near the catalogers) which means that we could remove this from the metadata object at that time.
This fixes some instances where the improved APK CPE generation logic caused regressions for older alpine package APK metadata. It now generates multiple "upstream" candidates with both name and package type which reduces the amount of duplicated code in the apk cpe gen logic. This also improves the handling of stream version packages, so now we can correctly identify packages such as ruby3.2-rexml as the rexml ruby gem. Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
This fixes some instances where the improved APK CPE generation logic caused regressions for older alpine package APK metadata. It now generates multiple "upstream" candidates with both name and package type which reduces the amount of duplicated code in the apk cpe gen logic. This also improves the handling of stream version packages, so now we can correctly identify packages such as ruby3.2-rexml as the rexml ruby gem.