Repository navigation
feat(analyzer): let the analyzer artifact self-report its build identity #390
Description
The second follow-up promised in #388, and a fuller answer to your question there about what "version self-report" meant.
Observed: the analyzer artifact carries no build identity we could find — no --version flag, no jar-manifest attribute, and the SARIF reports tool.driver.version: "latest". The project does publish semver releases (v0.4.5, 2026-07-10), but the dated analyzer/* releases we consume have shipped roughly ten times since then, so even a semver string baked into the jar wouldn't identify a build — the identity that would help is the dated release tag or commit, e.g. 2026.08.27.17eb0fe.
What we do today instead: our pin witnesses the SHA-256 of both release assets (opentaint-project-analyzer.jar, opentaint-models.tar.gz) before every run and publishes the release tag only when both match. That works, but it means every downstream consumer has to maintain their own digest table, and a bug report can't name its build from the artifact alone.
Ask: report the dated tag/commit on any (ideally all) of: a --version flag, the jar manifest (Implementation-Version), and SARIF tool.driver.version (or semanticVersion). Since the release tags already encode date + commit, this is presumably just threading the tag into the build.
(The other ergonomic ask from #388 — a non-debug all-methods entry-point flag — is resolved by your explanation there; we're keeping --debug-run-analysis-on-selected-entry-points=* pinned as part of our documented invocation.)
Posted via gh with Claude, who helped with the write-up.
Activity
Amendment A11: enable OpenTaint primitive tracking and re-run both ke…
misonijnik commentedon Sep 1, 2026
I see two ways to solve it.
Use our binary CLI (opentaint-full_linux_amd64.tar.gz) instead of
opentaint-project-analyzer.jar. This is the preferred way, and you'll get the right versions in the SARIF report out of the box.Use the
--sarif-tool-versionand--sarif-tool-semantic-versionoptions of opentaint-project-analyzer.jar to set these fields in the SARIF report yourself.DavidBakerEffendi commentedon Sep 1, 2026
Thanks for both suggestions. To be fair this is quite nitpicky and maybe we're the only ones who care about this. Your options cover 90% of people: we tested the CLI and it does stamp the dated tag correctly (
version: "analyzer/2026.07.10.a20ded6"), and the--sarif-tool-versionflags work on the jar.What doesn't work for us: we drive the jar directly since scan doesn't expose
--debug-run-analysis-on-selected-entry-points, which our fixtures need, and a version we pass in ourselves doesn't count as the tool reporting its identity, but we're not blocked. The GitHub release API reports SHA-256 digests for theanalyzer/*assets, so we can verify the jar we ran against those and get a reliable snapshot version that way.So treat this as a nice-to-have: baking the tag into the jar at build time (like your CLI already does externally) would let anyone with just the jar name its build. Feel free to triage or close as you see fit.
misonijnik commentedon Sep 1, 2026
@DavidBakerEffendi
It's quite a pain to bake the commit hash into the jar that was built from it. On the other hand, the CLI version can change without the jar changing, so we can't bake the CLI version into the jar either.
We can work around this: we can provide the
--debug-run-analysis-on-selected-entry-pointsflag through the CLI but keep it hidden. That means thehelpcommand won't show it by default, but you'll still be able to use it. Would that work for you?DavidBakerEffendi commentedon Sep 1, 2026
Yes I think that's the most practical solution, thanks
misonijnik commentedon Sep 3, 2026
@DavidBakerEffendi
The option is in main #395. It will be included in the next CLI release.
DavidBakerEffendi commentedon Sep 3, 2026
Solved by #395
misonijnik commentedon Sep 4, 2026
@DavidBakerEffendi
Hi! The v0.4.6 release is here!
You can look at our installation doc to see all the ways to install the CLI and choose the one that works best for you.
We also fixed a bunch of low-hanging FNs, so feel free to give OpenTaint another run for the next DataFlowBench release — we'd love to hear how it goes!
DavidBakerEffendi commentedon Sep 4, 2026
Thanks so much! Will do. Preparing a blog post around the next release so I'll likely share that via X and tag OpenTaint