Improve SCA handling of bogus shlib dependencies #2109
Merged
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.
A few issues have either been introduced or uncovered by two recent melange SCA changes:
6b78277:
SCA: Generate "depends" for shlibs ending in ".so"
b3bba3c:
Do not require .so files to be executable
melange is now processing more shared libraries and binaries when calculating the necessary dependencies of a package, and we're encountering weird cases. The root cause is almost always the same: some of our packages ship prebuilt binaries (ugh) for different systems/architectures. For example,
grafana-image-renderer
ships binaries compiled for Android.code-server
ships binaries linked against musl. Ideally we should fix these packages and get rid of these bogus binaries, but it's hard to cover the whole archive and detect all these cases.In order to unbreak some of the most common cases, I'd like to propose yet another heuristic for melange. Let's carry a list of libraries that are known to be bogus when they appear on
NEEDED
, so that we can ignore them during SCA. I realize that this is moving more policy inside the mechanism, and I'm not happy with it, but I talked to @jonjohnsonjr and @dannf and told them that I'd create a future roadmap item to proper move these lists out of our source code and into configuration files.