setup-jbang pipes curl|bash with no signature/checksum verification

[potiuk]

Summary

action.yml installs JBang by piping a remote shell script directly into bash (and iex on Windows):

- name: 'Download JBang'
  shell: bash
  if: runner.os != 'Windows'
  run: |
    curl -Ls https://sh.jbang.dev | bash -s - app setup
    ...

- name: 'Download JBang (Windows)'
  shell: pwsh
  if: runner.os == 'Windows'
  run: |
    iex "& { $(iwr https://ps.jbang.dev) } app setup"

There's no checksum, signature, or attestation verification of either the bootstrap script or the JBang archive it ultimately downloads.

Why this matters

The Apache Software Foundation runs a security checker (verify-action-build, https://github.com/apache/infrastructure-actions) on every action used by ASF projects. For setup-jbang@v0.1.1 it raises:

• pipe-to-shell (curl | sh) — high risk (action.yml line 28)
• 1 unverified download (the binary that ends up at ${HOME}/.jbang/bin)

That blocks adoption from ASF infra (apache/infrastructure-actions#806) until the install path verifies what it executes.

What's already there

jbangdev/jbang releases ship the verification material we need:

• checksums_sha256.txt + checksums_sha256.txt.asc (GPG-signed checksum file for all artifacts)
• Per-artifact .sha256 and .asc (e.g. jbang.zip.sha256, jbang.zip.asc)
• A versioned archive (jbang-X.Y.Z.zip / .tar) and unversioned aliases (jbang.zip / jbang.tar)

So an integrity-checked install is just a few extra lines — no new tooling needed.

Proposal

Replace the pipe-to-shell with an explicit download + verify, e.g. (Linux/macOS):

ver="${{ inputs.version }}"
curl -fsSLo jbang.zip        "https://github.com/jbangdev/jbang/releases/download/v${ver}/jbang-${ver}.zip"
curl -fsSLo jbang.zip.sha256 "https://github.com/jbangdev/jbang/releases/download/v${ver}/jbang-${ver}.zip.sha256"
sha256sum -c jbang.zip.sha256
unzip -q jbang.zip -d "${HOME}"
mv "${HOME}/jbang-${ver}" "${HOME}/.jbang"
echo "${HOME}/.jbang/bin" >> "$GITHUB_PATH"

…and the PowerShell equivalent (Get-FileHash -Algorithm SHA256 against the shipped .sha256).

For "latest", a small lookup step against the Releases API can resolve the tag first (or default inputs.version to a pinned tag rather than latest).

If you'd prefer GPG verification (gpg --verify jbang.zip.asc) or sigstore, those are also accepted by the ASF checker — happy to align on whichever path you prefer.

One more thing

This repo has no LICENSE file at the root — would be great to add one (Apache-2.0 / MIT / whatever matches the JBang project itself). It's also one of the metadata signals the ASF checker reports.

Happy to send a PR for the install-path change once you indicate which verification mechanism you'd like to standardize on.

[tiagobento]

Thanks for reporting this issue @potiuk!

Hi JBang team. I'm trying to use the jbangdev/setup-jbang action in an ASF project (KIE), and those enhancements would unblock it on ASF infra. Hope they make sense!

[quintesse]

Not sure what @maxandersen prefers, but anything is better than what there is now. And changing from sha256sum to gpg is a 1-line change, right? So I'd say go ahead with the PR. (Worst-case we'd want an option to turn on/off this verification.)

[maxandersen]

+1 on adding checksum verification.

I would prefer we still use /latest by default - not sure what the extra version lookup brings since if you want specific version you should be setting it explicitly ?

About license - MIT should be added.

[potiuk]

I would prefer we still use /latest by default - not sure what the extra version lookup brings since if you want specific version you should be setting it explicitly ?

Latest would not work if you want (relly good) checksum verification - > basically when you release a new verison and do the checksum, you always have to add the checksum to "known checksums" - so if you add latest, every time it's bumped, the action will fail.

[potiuk]

And just to add - the example above is just an example - but ideally checksums should be "embedded" in ation other than downloaded. I can easily imagine the scenario that someone updates both binary and checksum after breaking in to where the binary is hosted :D

[maxandersen]

You want setup-Jbang to bundle all possible checksums? Or at least be updated on every release.

I think that is a bit excessive forcing users to update setup-Jbang to get latest.

We have to strike a balance between ensuring users get latest, download checksum verified for correctness but also enable explicit check it has not been tampered with.

Hence my thinking always been for Jbang is that you get the latest by default ( that's what Jbang install.sh, maven, gradle and docker builds and probably a lot more does today), with option to lock to specific version - and that we should checksum the downloads for correctness - but allow users to explicit state a sha checksum to lock it.

Alternative where setup-Jbang has to be updated on every release ...how do you then ensure that setup-Java is correct ?

With my suggested above we got continuously updates with opportunity for user requested full verification.

Or are there some flow I'm missing?

[potiuk]

You're right that bundling per-release checksums is the wrong model. The piece that has to live in setup-jbang's source tree is the trust anchor, not the per-release SHA — and there's a way to do that without forcing an update on every JBang release.

GPG public key embedded in setup-jbang + downloaded .asc signature. At install time the action fetches jbang-X.Y.Z.zip.asc alongside the zip and runs gpg --verify against the embedded JBang signing key. That:

• works with latest (still resolved via the Releases API — nothing per-release in setup-jbang)
• survives a compromise of the release bucket — an attacker who swaps the zip + checksum can't forge a signature without the JBang signing key
• only needs to be touched when JBang rotates its signing key (rare)

This is the gap to install.sh / maven / gradle that you asked about: those rely on TLS to the same server, so they can't recover from a server-side compromise. Maven specifically pins signing keys at the repo-config level — embedding the public key in setup-jbang is the same pattern. The Docker analogue (@sha256:… digest) maps to an optional sha256: input below.

Suggested shape:

• Default: version: latest → resolve via Releases API → download zip + .asc → gpg --verify against the embedded key.
• Optional sha256: input: hard-lock to a specific build for users who want it.

Happy to send the PR (and a LICENSE) once you OK the direction.

[quintesse]

and runs gpg --verify

What should we do on systems that don't have gpg installed?

[potiuk]

and runs gpg --verify

What should we do on systems that don't have gpg installed?

Install it?

[potiuk]

What should we do on systems that don't have gpg installed?

It could also be sigstore signed for example - many of the OSS binaries now (including Python) for example) - are nowadays signed with sigstore which is modern, public-ledger way of signing stuff. And it's also natively supported by GitHub OIDC - The attestations of artifact in GitHub also uses it -> https://docs.github.com/en/actions/concepts/security/artifact-attestations - so you can provide signed attestations and verify your binaries with it when your binaries are build on GitHub. It's also easy to setup.

And binaries can be signed by both GPG and sigstore at the same time, no problem with it. Also GitHub has ready - to use actions that allow you to verify such attestations and if you are using it with GitHub Actions, it should just work

[quintesse]

Install it?

Sure, so you see this solely as something for the GH action, right? Not as a general JBang feature. (Just making sure I understand)

[potiuk]

Absolutely - just for GH actions.