fix(REGISTRY-006-2): CU-86akbhhau jsign JAR download in release.yml uses SHA-256 verification correctly, but the code-signing token is passed via storepass on the command line, exposing it in process listings

[flamingo]

Closes findings from rule REGISTRY-006-2 — jsign JAR download in release.yml uses SHA-256 verification correctly, but the code-signing token is passed via storepass on the command line, exposing it in process listings.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🔴 55 low — review closely	jsign JAR download in release.yml uses SHA-256 verification correctly, but the code-signing token is passed via storepass on the command line, exposing it in process listings	scripts/sign-binary.sh:76

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: 82c9c576-edf0-420c-92b6-727226d68389

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akbhhau OpenFrame CLI code duplication and manager fixes (11 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

1 finding(s) fixed in this draft — 1 explained inline on the diff; 1 low-confidence hunk(s) need close review before merging.

[flamingo]

🦩 🔴 jsign JAR download in release.yml uses SHA-256 verification correctly, but the code-signing token is passed via storepass on the command line, exposing it in process listings

In sign_windows(), replaced --storepass "$token" CLI argument with the JSIGN_STOREPASS environment variable set only for the java -jar "$JSIGN_JAR" ... invocation (JSIGN_STOREPASS="$token" java -jar ...), preventing the token from appearing in ps//proc/<pid>/cmdline output. Also added unset token after use to limit its lifetime in the shell environment. This relies on jsign supporting the JSIGN_STOREPASS environment variable as a fallback for --storepass, which I could not verify against the installed jsign version in this repo; if that specific env var name is not supported by the jsign release in use, a complete fix would need to confirm the exact variable name from jsign's documentation/source for the pinned version, or alternatively pipe the token via stdin/a file descriptor if jsign supports --storepass @file/env: style syntax instead.

🤖 Prompt for AI agents

In scripts/sign-binary.sh around line 76, review and complete this code-review fix: jsign JAR download in release.yml uses SHA-256 verification correctly, but the code-signing token is passed via storepass on the command line, exposing it in process listings.
What the draft fix changed: In sign_windows(), replaced `--storepass "$token"` CLI argument with the `JSIGN_STOREPASS` environment variable set only for the `java -jar "$JSIGN_JAR" ...` invocation (`JSIGN_STOREPASS="$token" java -jar ...`), preventing the token from appearing in `ps`/`/proc/<pid>/cmdline` output. Also added `unset token` after use to limit its lifetime in the shell environment. This relies on jsign supporting the `JSIGN_STOREPASS` environment variable as a fallback for `--storepass`, which I could not verify against the installed jsign version in this repo; if that specific env var name is not supported by the jsign release in use, a complete fix would need to confirm the exact variable name from jsign's documentation/source for the pinned version, or alternatively pipe the token via stdin/a file descriptor if jsign supports `--storepass @file`/`env:` style syntax instead.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 55 low — review closely — react 👍/👎 to teach the reviewer