v0.3.14 Windows ARM64 installer checksum mismatch

[michaelburch]

The v0.3.14 Windows ARM64 CLI installer checksum sidecar does not match the release asset.

Asset:
geniex-cli-setup-windows-arm64-v0.3.14.exe

Sidecar:
geniex-cli-setup-windows-arm64-v0.3.14.exe.sha256

Expected from sidecar:
170fd1d9ba67f79d68b624552f8c614188da0c632d8c11fc13e1822aecd1cede

Actual SHA256 from a fresh GitHub release download:
15e8fac5e074e63ed41e43cd6303e2b950ecc46f956bb1b575dc12a1c8a8e0ad

Repro:

curl -fsSL https://github.com/qualcomm/GenieX/releases/download/v0.3.14/geniex-cli-setup-windows-arm64-v0.3.14.exe -o /tmp/geniex.exe
sha256sum /tmp/geniex.exe
curl -fsSL https://github.com/qualcomm/GenieX/releases/download/v0.3.14/geniex-cli-setup-windows-arm64-v0.3.14.exe.sha256

[mengshengwu]

Hi Michael, thanks for reporting.

The mismatch is because our current CI-produced installer is not code-signed. After the team submits the build to Qualcomm's signing team, we replace the release asset with the signed .exe in place — but the .sha256 sidecar was generated against the pre-signed binary, so the two no longer match.

We'll improve this flow so the sidecar always tracks the actually-published asset. Sorry for the confusion.

[mansiverma897993]

Hi Zack Li (@zhiyuan8) I'd be happy to help resolve this one if you're open to a contribution.

Since the signed .exe is swapped in after CI, the sidecar can't be fixed at build time so my thought is a small workflow_dispatch job (e.g. refresh-checksums) that takes a tag, downloads the currently-published release assets, recomputes the .sha256 sidecars against them, and re-uploads any that drifted. The operator would run it once right after the signed installer is swapped in, so the sidecar always tracks the actually-published asset, as you described.

One extra data point: geniex update also verifies SHA256 from the update manifest (verifySHA256 in cli/cmd/geniex/update.go), so if the manifest hash is also generated pre-signing, auto-update would fail the integrity check too worth covering in the same flow.

Would a PR along these lines be welcome, or is this being handled in the internal signing-delivery flow? Happy to adjust the approach to whatever fits.