Catalog JDKs more completely #3188
Assignees
Labels
Comments
kzantow
added
enhancement
|
I good path appears to be using the release file that is published with multiple jdk distributions / packagings: /opt/java/openjdk/release/usr/lib/jvm/zulu19-ca-arm64/releaseContainer: Packaging info: /usr/lib/jvm/java-17-amazon-corretto/releaseContainer: Packaging info: /usr/lib/jvm/java-17-openjdk-17.0.12.0.7-2.el8.aarch64/releaseAfter installing /opt/java/openjdk/release/opt/java/openjdk/release/usr/lib/jvm/jdk-22.0.2-bellsoft-aarch64/releaseContainer: /usr/lib/jvm/msopenjdk-17/releaseContainer: Packaging info: /usr/lib/jvm/sapmachine-16/releaseContainer: Packaging info: /usr/lib/jvm/jdk-22.0.2-oracle-aarch64/releaseI haven't been able to find any JEPs that define this file in detail (so far only some distant references here), but for the temurin flavor, here's the PR that put in this enhancement (thus, where these fields are derived from): https://github.com/adoptium/temurin-build/pull/2049/files . In terms of associating files with each distribution, it would be all sibling and child files found relative to the release file. Something to note: some of these above examples are already packaged in RPMs, which we don't want to additionally catalog. Instead, we're interested in unpackaged distributions. |
|
I'm not sure if it adds anything you haven't already looked at, but I had captured some similar notes over on #2422 (comment) |
|
Indeed -- I was going to link these two issues together and close them in an upcoming PR. I'm using your notes to try and get the crafted CPEs and purl correct 🤞 . |
|
This will also solve #1426, I think. And please let me share one episode, I faced on recently. As OracleJDK 17 under NFTC (free license) will be end soon, Oracle seems more active... |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What would you like to be added:
A custom cataloger specifically for JDK distributions.
Why is this needed:
Today, Syft catalogs JDKs by identifying
javaexecutables with a generic binary cataloger. This works marginally well, but only is able to catalog thejavaexecutable itself. There are many other executable files and libraries associated with the JDK that are not included by this cataloging, but it would be great for Syft to be able to correctly identify these files with relationships to an identified JDK version, such as OpenJDK or Oracle JDK, etc..Additional context:
For example, in the docker official images, there are 25 instances of
/opt/java/openjdk/bin/keytool, which a user can identify as being part of the openjdk but Syft does not associate with any package. If we scan the official Docker images, these files are found, with the total number of times found see:Common OpenJDK files
Many of these are prevalent enough in modern software stacks, that Syft should be able to accurately identify these files and associate them with the OpenJDK distribution, where applicable.
A potential solution is to create a Java / JDK cataloger for the distributions and runtimes themselves.
Another possibility is to augment the binary cataloger with some
if-found-also-includerelative paths or similar.The text was updated successfully, but these errors were encountered: