Skip to content

Offer an allowlist-free CLI install mode (binary fetch) as a generator flag #651

Description

@joshua-temple

Problem

Generated workflows install the CLI via a single remote action reference:
uses: stablekernel/cascade/.github/actions/setup-cli@<pinned-ref>. That is a
third-party action. Organizations that run a GitHub Actions allowlist must approve
it before any generated pipeline can run, which is a real adoption barrier for
locked-down enterprise consumers. A shell-based binary fetch is not a third-party
action and does not hit the allowlist, so offering it removes that barrier and fits
the "compiler, not control plane" positioning (less runtime coupling to this repo).

Proposal

Add a generator flag, --cli-install=action|binary (default action), in the
functional-options style so it is additive and non-breaking:

  • action (default): current behavior. Best ergonomics for orgs that allow the
    action (built-in cache, version resolution, cosign verification).
  • binary: emit the equivalent install as inline steps with no third-party
    uses:. Must preserve verification, not just download. First-party
    actions/cache is retained for the download cache (first-party actions are
    acceptable to allowlisted orgs), so caching coverage is unchanged.

The download-and-verify logic already lives in a standalone install.sh exercised
hermetically by internal/setupcli; the binary mode should reuse or mirror that
verification path rather than shipping an unverified curl | tar.

Verification: allowlist-free does not force gpg

Releases are dual-signed (.goreleaser.yaml): cosign KEYLESS (OIDC + Sigstore +
Rekor, provenance-bearing) and GPG (passphraseless key). Keep both; do NOT drop
cosign signing. "Allowlist-free" only requires dropping the sigstore/cosign-installer
ACTION, not cosign itself. cosign is a single static binary, so the binary mode can
offer either verification path:

  • GPG verify: simplest, ubiquitous tool, but weaker (integrity + key-holder only,
    no provenance).
  • cosign keyless verify with cosign fetched by curl (not the installer action):
    stronger, keeps workflow-identity provenance, still allowlist-free, one extra
    download.

Prefer curl-installed cosign keyless where the consumer cares about provenance;
offer gpg as the convenience path. Do not bake in "binary mode == gpg only".

Prerequisites (already satisfied)

The GPG public key is already published (docs/cascade-release-public-key.asc,
committed in #395, uid "Cascade Release Signing"), shipped as the checksums.txt.asc
release asset, and both verify paths are documented in
docs/src/content/docs/security.md. No new publishing work is required before the
binary mode can verify.

Acceptance

  • Generator flag with both modes; action output byte-identical to today.
  • An e2e/ scenario for the binary mode asserting the emitted steps verify the
    signature and checksum (not merely download), for whichever verify path(s) ship.
  • Docs for the new flag under docs/src/content/docs/ and the README where install
    is described; link the existing verification section in security.md.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dxDeveloper experiencegeneratorpost-1.0securitySecurity hardening and code-scanning findings

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions