Repository navigation
feat: Publish and verify SHA-256 checksums for standalone Hive CLI archives #8455
Description
Activity
While implementing the installer follow-up, we found a rollout/compatibility decision that needs maintainer guidance.
Historical standalone archives exist without publisher manifests. For example, as of 2026-10-02:
0.65.0 archive=200 manifest=404 0.64.1 archive=200 manifest=404 0.64.0 archive=200 manifest=404 0.50.1 archive=200 manifest=404Making
install.shrequire/versions/VERSION/SHA256SUMSfor every explicit version would therefore break the documented pinned-install flow for those releases. We see two reasonable policies:- Backfill manifests (preferred): generate and publish
SHA256SUMSfor historical versions whose standalone archives are still present. The installer can then use one mandatory-verification path for both old and new versions. - Set a cutoff: declare the first release guaranteed to have manifests (for example
0.67.0; exact version to be chosen when publishing lands). The installer preserves the legacy unverified path below that version and requires verification at/above it, with no fallback on verification failures.
Would you prefer a historical backfill, or should we establish a first checksummed-version cutoff?
NB: We also found that npm
latestis not a reliable authority for the standalone stable artifact: npm currently reports0.66.0, its versioned standalone archive returns 404, and/channels/stable/hive-…tar.gzreturns 200. I am updating the publishing PR to write/channels/stable/VERSIONas the last promotion step, so the installer can resolve the stable channel to the exact immutable version before verification.Reacted by Laurin- Backfill manifests (preferred): generate and publish
Approach 1. seems reasonable!
Thank you for maintaining the Hive CLI.
The documented installer currently downloads a platform archive from
cli.graphql-hive.comand extracts it without verifying a publisher-provided checksum or signature. Downstream consumers that pin the CLI therefore have to download each archive, calculate their own hashes, and trust that initial download. Which is a bit of a charade, which is the reason for this request.Would you consider generating a
SHA256SUMSmanifest during the existing release workflow, covering all supported archives, and publishing it at:Plain text
It would also be helpful for
install.shto verify the selected archive before extraction.Publishing the archives and checksum manifest on the corresponding GitHub release would provide a separate, discoverable source for downstream package definitions and pinned installations. As a further improvement, immutable releases and GitHub artifact attestations or Sigstore signing could bind the artifacts to the release workflow and source commit.
Publisher-generated hashes would be a useful first step and remove the need for consumers to establish their own trust-on-first-use pins.
Would this fit Hive’s current release model?