Skip to content

fix(java): resolve uber-jar version from root version.properties (issue #5163) - #5219

Open
CAOShurong wants to merge 3 commits into
anchore:mainfrom
CAOShurong:codex/5163-uberjar-versionproperties
Open

fix(java): resolve uber-jar version from root version.properties (issue #5163)#5219
CAOShurong wants to merge 3 commits into
anchore:mainfrom
CAOShurong:codex/5163-uberjar-versionproperties

Conversation

@CAOShurong

Copy link
Copy Markdown
Contributor

Description

Resolves #5163.

Some build tools (e.g. Clojure's build.clj, used by Metabase) record the version only in a root-level version.properties file (key tag), not in the manifest, filename, or pom.properties. Syft previously emitted UNKNOWN, which dropped the version from the purl and CPE and broke downstream vulnerability matching (e.g. the recent Metabase security advisory).

This adds a final fallback in discoverNameVersionLicense that reads the tag (or version) key from a root version.properties after the existing manifest/filename/pom checks fail.

Verification

End-to-end, scanning a minimal metabase.jar (no version in manifest or filename; only version.properties with tag=v0.63.5):

  • Before: metabase@UNKNOWN, purl pkg:maven/metabase/metabase (no version), CPE wildcard
  • After: metabase@v0.63.5, purl pkg:maven/metabase/metabase@v0.63.5, CPE cpe:2.3:a:metabase:metabase:v0.63.5:*:*:*:*:*:*:*

A regression test fixture (metabase-version-properties) and a Test_parseJavaArchive_regressions case are included.

Checklist

  • Added / updated unit tests
  • go vet ./syft/pkg/cataloger/java/ passes
  • Commit is DCO-signed

Note: the in-repo jar-metadata test fixtures are normally generated via make in testdata/jar-metadata; the new fixture follows the same layout.

CAOShurong and others added 2 commits August 24, 2026 20:11
…ons.lock lockfiles

Signed-off-by: Shurong Cao <CAOShurong@users.noreply.github.com>
anchore#5163)

Some build tools (e.g. Clojure's build.clj, used by Metabase) record the
version only in a root-level `version.properties` file (key `tag`), not in
the manifest, filename, or pom.properties. Syft previously emitted
`UNKNOWN`, dropping the version from the purl and CPE and breaking
downstream vulnerability matching.

Add a final fallback in discoverNameVersionLicense that reads the `tag`
(or `version`) key from a root `version.properties` after the existing
manifest/filename/pom checks fail.

Verified end-to-end: a minimal metabase.jar (no version in manifest or
filename, only version.properties with tag=v0.63.5) now catalogs as
metabase@v0.63.5 (pkg:maven/metabase/metabase@v0.63.5, CPE with version)
instead of metabase@UNKNOWN.

Signed-off-by: Shurong Cao <CAOShurong@users.noreply.github.com>
…back

The glob **/version.properties also matches nested third-party
version.properties files that uber-jars commonly vendor (the real
Metabase jar ships ~40 of them). Any vendored copy containing a tag= or
version= key could win depending on zip entry order and attach a
dependency's version to the application package.

Tighten the match to the exact root entry and defensively filter matches
to the root path before extraction.

Regression test: a nested clojure/version.properties carrying a poison
value is added to the metabase-version-properties fixture; the cataloged
version stays v0.63.5 from the root file (the previous glob resolves the
poison value instead).

Signed-off-by: Shurong Cao <CAOShurong@users.noreply.github.com>
Signed-off-by: Shurong Cao <170531907+CAOShurong@users.noreply.github.com>
@CAOShurong

Copy link
Copy Markdown
Contributor Author

Pushed a hardening commit (eb7e500e) implementing the root-path tightening discussed in the thread above:

  • versionPropertiesGlob is now the exact root path "/version.properties" instead of **/version.properties
  • matches are additionally filtered to the exact root entry before extraction, so a nested third-party file can never win regardless of glob semantics or zip entry order

Verified with a real regression test: added a vendored clojure/version.properties (keys tag=9.9.9-poison, version=9.9.9-poison) to the metabase-version-properties fixture — mirroring the ~40 nested files present in the official Metabase jar. On the previous glob this poisons the cataloged version (reproduced: package resolves to 9.9.9-poison instead of v0.63.5); after this commit the version stays v0.63.5 from the root file.

Note for reviewers: running the java cataloger suite on Windows hits pre-existing path-separator mismatches (testdata\ vs testdata/) unrelated to this change; on Linux CI the suite runs clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

java-archive-cataloger returns unknown ver for uber-jars

1 participant