Weston Steimel

As an example I have updated my personal container build of curl to include ELF package metadata information: https://github.com/westonsteimel/container-library-curl/blob/f80180dd91998524f26c363e2d8b924af91d14ac/stable/Dockerfile#L53 ``` readelf -n /usr/local/bin/curl Displaying notes found in: .note.package Owner Data...

I think it's all java versions prior to 9 that would be prefixed with a 1 in the jdk

The `_` suffix seems to correspond to update, so if we enhanced the syft logic to interpret the _{XXX} as updateX in the cpe component then that would help some...

I wonder if we should have a more specific cataloger for detecting java jdk and jre rather than a generic binary cataloger. For instance, the image `eclipse-temurin:11.0.21_9-jre-alpine` has the following...

Seems to be present for versions 11 and above at least for the `eclipse-temurin` and `ibmjava` images

Sorry, I went off on a bit of a tangent, we'd still need the same sort of adjustments to the CPE generation, I was just looking at getting additional metadata...

I think we should just special case the version comparison logic in grype and forget about trying to make the CPEs perfect in syft since we know that will never...

Some very rough initial notes which may be useful for a future java installation cataloger: - Consider the properties from $JAVA_HOME/release file if it exists - Attempt to determine JVM...

My original thought was to potentially add a new ecosystem value for these, so could be something like: - `Rust` - `Nodejs` - `Python` Where the `name` would then be...

As a note I would expect this to start out very narrowly scoped to cover existing well-known tools that are important parts of language ecosystems and are not frequently installed...