Skill

test-release-canary

skill:nvidia/openshell#test-release-canary

Manually dispatch and iterate on the Release Canary workflow that smoke-tests published OpenShell artifacts (install.sh on macOS/Ubuntu/Fedora, Helm chart on kind) after each Release Dev publish. Use when changing `.github/workflows/release-canary.yml`, validating a release before tagging, debugging a canary failure, or reproducing a canary job locally. Trigger keywords - release canary, release-canary, canary failed, canary dispatch, test release canary, post-release smoke, install.sh canary, helm chart canary, kind canary, dispatch canary.

SkillsMP

Verdict

Suspicious

Risky behavior the analysis could not rule out.

Analyzed Oct 27, 2026, 21:56 UTC at fa2d381

findings

—

highest severity

threat classes

2,140

files scanned

69/69

checks satisfied

package advisories

Why this verdict

suspicious: floor fact PY-FETCH-EXEC-INSTRUCTED (DET:027680748b28f391)
suspicious: floor fact PY-FETCH-EXEC-INSTRUCTED (DET:6b2a42b1e58627f2)
suspicious: floor fact PY-FETCH-EXEC-INSTRUCTED (DET:8c66261b28c2c147)

Security findings 0

No individual findings recorded

The suspicious verdict rests on the open questions and coverage gaps below; 5 candidate findings were refuted on review.

Open questions 5

What the analysis could not settle from the code alone.

Residue R1/R2 in e2e/support/install-agent-sandbox.sh (reading env AGENT_SANDBOX_VERSION with default v1.0.3; fetching https://github.com/kubernetes-sigs/agent-sandbox/releases/download/$VERSION manifest and kubectl-applying it) was adjudicated necessary because the declared kind smoke test creates sandboxes, which plausibly requires the upstream Agent Sandbox CRDs/controller installed before the chart; the chart's exact dependency on those CRDs is not shown in this batch.

[file request install.sh] The canary jobs execute this installer via curl piped to sh at a commit-resolved raw.githubusercontent.com URL: does install.sh restrict its downloads and actions to the declared OpenShell release/registry channels, or does it contact additional hosts, read credentials, or write startup/config files beyond what the canary documentation describes?

Code execution

[file request install.sh] The release-canary jobs (macos, ubuntu-deb, fedora, ubuntu-snap, kubernetes) fetch install.sh from raw.githubusercontent.com/NVIDIA/OpenShell at the pinned head SHA and pipe it to sh; does install.sh at that path only install the OpenShell packages/services needed for the smoke test, without additional network destinations, credential access, or persistence?

Code execution

[file request install.sh] The canary jobs fetch this script and pipe it into sh (curl -LsSf .../install.sh | sh): what network destinations, credential or environment access, service installs (systemd/brew/snap/launchd), or writes outside the install prefix does install.sh perform, and does any of it send runner data off-host?

Code execution

[file request .github/workflows/release-dev.yml] Which commit and branches does the Release Dev workflow run on, so the canary's install.sh URL (github.event.workflow_run.head_sha || github.sha) can be confirmed to always resolve to this repository's own reviewed content?

Supply chain

Refuted findings 5

Candidates the review stage examined and rejected, kept for transparency.

Code execution

criticalRefutedhigh confidence

The release-canary workflow pipes install.sh fetched from raw.githubusercontent.com at a runtime-resolved commit SHA directly into sh, executing installer content whose behavior is not fixed by this pinned commit.

.github/workflows/release-canary.yml:182

curl -LsSf

Why it was refuted

Executing install.sh is the skill's declared core capability (the 'install.sh canary' the description exists for, referenced in SKILL.md as the canary's install step), and the URL embeds the full triggering commit SHA (workflow_run.head_sha || github.sha), which fixes the raw content — so the claim that behavior 'is not fixed by this pinned commit' mischaracterizes the evidence.

Supply chain

criticalRefutedlow confidence

The canary and the skill's local reproduction install the helm chart at the floating mutable tag 0.0.0-dev from ghcr.io/nvidia/openshell, so the deployed code is whatever that mutable tag currently holds rather than a pinned digest.

.github/workflows/release-canary.yml:418-424

--version 0.0.0-dev

Why it was refuted

The 0.0.0-dev tag is explicitly declared as 'floating, overwritten on every main push' with a documented 0.0.0-dev.<sha> pinning alternative, and the kubernetes job runs only after the Release Dev run that overwrote that tag, so the declared smoke-test deploys the just-published build under test rather than undeclared arbitrary mutable content.

Supply chain

criticalRefutedlow confidence

The skill instructs running e2e/support/install-agent-sandbox.sh, which downloads a release manifest from github.com/kubernetes-sigs/agent-sandbox at an environment-overridable version and kubectl-applies it into the cluster without asset verification.

e2e/support/install-agent-sandbox.sh:41-43

kubectl

Why it was refuted

The helper installs the official kubernetes-sigs/agent-sandbox release manifest at a version pinned by both the script default and the workflow env (v1.0.3) into a per-run disposable kind cluster, and both the script header and the skill's Local kind reproduction openly declare the step — a pinned official-source install carve-out, not an unverified supply chain.

Persistence

highRefutedlow confidence

The snap canary job enables the snapd systemd socket and enables login-linger for a created test user, host service-enablement writes that would persist beyond the session on a non-ephemeral host.

.github/workflows/release-canary.yml:206-207

sudo systemctl enable --now snapd.socket

Why it was refuted

Enabling snapd.socket and login-linger for a job-created test user are overt, named setup steps ('Install snapd') of the declared Ubuntu snap canary running on a disposable GitHub-hosted ubuntu-latest runner, so nothing persists beyond the ephemeral job VM.

Privilege escalation

mediumRefutedlow confidence

The Fedora job launches a privileged Docker container with host cgroup namespace and /sys/fs/cgroup mounted read-write on the CI runner to run systemd as PID 1 while testing the RPM installer, granting the container near-host privileges.

.github/workflows/release-canary.yml:104-116

--privileged

Why it was refuted

The --privileged systemd container is the overt, purpose-built mechanism of the declared Fedora RPM canary — the workflow comments that systemd-as-PID-1 is needed so install.sh's RPM gateway systemd user unit can be exercised — on a disposable CI runner, and it is force-removed in an always() step; this is declared-core-capability/broad-permissions behavior, not a privilege-escalation chain.

Coverage gaps 42

Parts of the artifact the static analysis could not fully examine.

context:manifest_unparseable yaml: YAML aliases are not permitted

.github/workflows/build-binaries.yml

context:manifest_unparseable yaml: YAML aliases are not permitted

.github/workflows/build-images.yml