Skip to content

fix(security): replace curl|sh installer pipes with download+verify (RGS-018) #43716

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Copilot wants to merge 8 commits into
base: main
Choose a base branch
from
+61 −17
Open

fix(security): replace curl|sh installer pipes with download+verify (RGS-018) #43716

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
a357996
Initial plan
Copilot Jul 6, 2026
3eca684
Initial plan checkpoint
Copilot Jul 6, 2026
98a1883
fix(security): replace curl|sh installer patterns with download+verif…
Copilot Jul 6, 2026
d265668
Merge branch 'main' into copilot/static-analysis-report-2026-07-06
pelikhan Jul 6, 2026
0821ca9
fix: use /tmp/gh-aw/ folder for installer temp files
Copilot Jul 6, 2026
5c2c9d0
Merge branch 'main' into copilot/static-analysis-report-2026-07-06
pelikhan Jul 6, 2026
efc3075
fix(security): pin installer refs to resolved SHA in dev-mode templat…
Copilot Jul 6, 2026
157710a
Merge remote-tracking branch 'origin/main' into copilot/static-analys…
Copilot Jul 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/copilot-setup-steps.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,12 +13,12 @@ jobs:
permissions:
contents: read
steps:
- name: Install gh-aw extension
run: curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh | bash
- name: Checkout code
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
with:
persist-credentials: false
- name: Install gh-aw extension
run: bash install-gh-aw.sh
- name: Set up Node.js
uses: actions/setup-node@395ad3262231945c25e8478fd5baf05154b1d79f
with:
Expand Down
13 changes: 10 additions & 3 deletions .github/workflows/daily-byok-ollama-test.lock.yml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

9 changes: 8 additions & 1 deletion .github/workflows/daily-byok-ollama-test.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,15 @@ strict: true
timeout-minutes: 20
steps:
- name: Install Ollama
env:
OLLAMA_VERSION: "0.31.1"
OLLAMA_INSTALL_SHA256: "25f64b810b947145095956533e1bdf56eacea2673c55a7e586be4515fc882c9f"

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHA256 hash and version are not atomically coupled — a version bump without a hash update will silently break secret scanning or Ollama installation.

💡 Details

OLLAMA_INSTALL_SHA256 is coupled to OLLAMA_VERSION: "0.31.1". When OLLAMA_VERSION is bumped (manually or via Dependabot), the hash will be wrong. The sha256sum -c command will fail with a non-zero exit code, causing the entire install step to fail — and since this workflow is the only mechanism for Ollama availability, all downstream steps will also fail.

The same concern applies to TRUFFLEHOG_SHA256 / TRUFFLEHOG_VERSION in shared/trufflehog.md.

There is no comment, script, Makefile target, or CI check enforcing the coupling. Add a comment documenting the procedure:

# To update: run scripts/update-installer-hashes.sh or:
# curl -fsSL https://github.com/ollama/ollama/releases/download/vVERSION/install.sh | sha256sum
OLLAMA_VERSION: "0.31.1"
OLLAMA_INSTALL_SHA256: "25f64b810b947145095956533e1bdf56eacea2673c55a7e586be4515fc882c9f"

Consider adding a CI check that validates the stored hash against the pinned version, or a make update-hashes target.

run: |
curl -fsSL https://ollama.com/install.sh | sh
echo "Downloading Ollama v${OLLAMA_VERSION} install script..."
mkdir -p /tmp/gh-aw
curl -fsSL "https://github.com/ollama/ollama/releases/download/v${OLLAMA_VERSION}/install.sh" -o /tmp/gh-aw/ollama-install.sh
echo "${OLLAMA_INSTALL_SHA256} /tmp/gh-aw/ollama-install.sh" | sha256sum -c -
sh /tmp/gh-aw/ollama-install.sh

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/diagnosing-bugs] install.sh is a shell script that runs as root — SHA256-verifying the script bytes is correct, but the hash itself is hardcoded and will silently pass once it is stale after Ollama releases a patched install.sh for the same version tag.

If Ollama ever re-publishes the same-version script with different content (unlikely but possible with installer scripts), this check won't catch it until the constant is manually updated.

💡 Suggestion

Consider documenting in the env block where the SHA256 was sourced (e.g., from the Ollama release page checksum file). Also add a set -euo pipefail at the top of the run block to ensure the sha256sum -c - failure propagates:

run: |
  set -euo pipefail
  echo "Downloading Ollama v${OLLAMA_VERSION} install script..."
  mkdir -p /tmp/gh-aw
  curl -fsSL "..."
  echo "${OLLAMA_INSTALL_SHA256}  /tmp/gh-aw/ollama-install.sh" | sha256sum -c -
  sh /tmp/gh-aw/ollama-install.sh

The current script lacks set -euo pipefail, so a failed sha256sum could be silently ignored if bash is invoked non-strictly.

@copilot please address this.

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ollama install script run with sh instead of bash — will silently fail or produce errors on Ubuntu where sh is dash.

💡 Details

On Ubuntu runners, /bin/sh is dash, not bash. The Ollama install script uses bash-specific syntax: local declarations in functions, [[ conditionals, array assignments, and process substitution. Running it under dash produces either a parse error that aborts installation mid-way, or silent failure where bash-specific features are skipped.

The fix already applied to copilot-setup-steps.yml uses bash — use that consistently here:

bash /tmp/gh-aw/ollama-install.sh

- name: Generate Ollama API key
run: |
OLLAMA_API_KEY="$(openssl rand -hex 16)"
Expand Down
8 changes: 6 additions & 2 deletions .github/workflows/shared/trufflehog.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,9 +38,13 @@ jobs:
id: install-trufflehog
env:
TRUFFLEHOG_VERSION: "3.88.27"
TRUFFLEHOG_SHA256: "e3b2647b7a7bc1591f316da91fd33fc7397f8e3c21e2feed791c171f0c406bc7"
run: |
echo "Installing TruffleHog v${TRUFFLEHOG_VERSION}..."
curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin "v${TRUFFLEHOG_VERSION}"
echo "Downloading TruffleHog v${TRUFFLEHOG_VERSION}..."
mkdir -p /tmp/gh-aw
curl -fsSL "https://github.com/trufflesecurity/trufflehog/releases/download/v${TRUFFLEHOG_VERSION}/trufflehog_${TRUFFLEHOG_VERSION}_linux_amd64.tar.gz" -o /tmp/gh-aw/trufflehog.tar.gz

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded linux_amd64 architecture makes this URL non-portable and will silently fail on ARM runners.

💡 Details and fix

The download URL:

https://github.com/trufflesecurity/trufflehog/releases/download/v${TRUFFLEHOG_VERSION}/trufflehog_${TRUFFLEHOG_VERSION}_linux_amd64.tar.gz

...hardcodes linux_amd64. GitHub's hosted ubuntu-latest runners include ARM variants, and any self-hosted runner on a non-x86 architecture will download the wrong binary. The SHA256 check will then fail (correct behavior), but the failure message will be confusing and the job will break silently.

Additionally, if the SHA256 is ever inadvertently changed to match the wrong-arch binary, the extracted trufflehog binary will fail to execute, disabling secret scanning without a clear error.

Detect architecture at runtime:

ARCH=$(dpkg --print-architecture 2>/dev/null || uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl -fsSL "https://github.com/trufflesecurity/trufflehog/releases/download/v${TRUFFLEHOG_VERSION}/trufflehog_${TRUFFLEHOG_VERSION}_linux_${ARCH}.tar.gz" \
  -o /tmp/gh-aw/trufflehog.tar.gz

This requires maintaining per-arch hashes (e.g., in an env map or a separate verification step that fetches the upstream file from the pinned release).

echo "${TRUFFLEHOG_SHA256} /tmp/gh-aw/trufflehog.tar.gz" | sha256sum -c -
sudo tar -xzf /tmp/gh-aw/trufflehog.tar.gz -C /usr/local/bin trufflehog

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/diagnosing-bugs] tar -xzf ... -C /usr/local/bin trufflehog extracts directly from the unverified archive position — the tarball was verified before extraction, which is correct, but consider the integrity check format: the SHA256 is for the .tar.gz file while the binary inside the archive is what ultimately runs.

This is architecturally sound (hash the archive, extract the binary), but the pattern diverges from the Ollama fix where the script itself is hashed. A brief comment would help future maintainers understand why this is intentional.

💡 Suggestion

Add an inline comment:

# SHA256 covers the .tar.gz archive; the binary is extracted from the verified archive
echo "${TRUFFLEHOG_SHA256}  /tmp/gh-aw/trufflehog.tar.gz" | sha256sum -c -
sudo tar -xzf /tmp/gh-aw/trufflehog.tar.gz -C /usr/local/bin trufflehog

Also note that sudo tar with --no-same-owner would prevent any embedded ownership metadata from affecting the system.

@copilot please address this.

trufflehog --version

- name: Scan agent output for secrets
Expand Down
10 changes: 7 additions & 3 deletions .github/workflows/smoke-codex.lock.yml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

34 changes: 28 additions & 6 deletions pkg/cli/copilot_setup.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,8 +82,15 @@ jobs:
`, actionRepo, actionRef, version)
}

// Default (dev/script mode): use curl to download install script
return `name: "Copilot Setup Steps"
// Default (dev/script mode): try to resolve the main branch to a pinned SHA so the
// downloaded script is immutable; fall back to the mutable branch ref if unavailable.
installRef := "refs/heads/main"
if sha, err := workflow.ResolveGhAwRef(ctx, "main"); err == nil && sha != "" {
installRef = sha
} else {
copilotSetupLog.Printf("Could not resolve github/gh-aw main SHA for dev-mode template, falling back to mutable ref: %v", err)
}
return fmt.Sprintf(`name: "Copilot Setup Steps"

# This workflow configures the environment for GitHub Copilot Agent with gh-aw MCP server
on:
Expand All @@ -105,10 +112,15 @@ jobs:
steps:
- name: Install gh-aw extension
run: |
curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh | bash
`
mkdir -p /tmp/gh-aw
curl -fsSL https://raw.githubusercontent.com/github/gh-aw/%s/install-gh-aw.sh -o /tmp/gh-aw/install-gh-aw.sh
bash /tmp/gh-aw/install-gh-aw.sh
Comment on lines 112 to +117

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue as in copilot-setup-steps.yml: the generated template downloads install-gh-aw.sh from the mutable refs/heads/main ref without integrity verification.

Since this Go code generates the workflow snippet that users copy-paste or auto-apply, users who run gh aw copilot-setup will get a configuration with the same unverified-mutable-URL problem. The fix should propagate here too — either pin the SHA in the template constant or, if keeping main is intentional for bootstrap flexibility, add an explicit sha256sum check in the generated snippet.

@copilot please address this.

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/codebase-design] The Go template generates a copilot-setup-steps.yml that does not SHA256-verify install-gh-aw.sh, creating an asymmetry between the security guarantee given in generated workflows vs. the TruffleHog/Ollama patterns also in this PR.

Users who run gh aw setup to scaffold their own workflow will get the less-secure (download-only) variant, while the repo's own copilot-setup-steps.yml has the same gap.

💡 Suggestion

If SHA256 verification is to be added to install-gh-aw.sh (as suggested for copilot-setup-steps.yml), the constant strings in copilot_setup.go need updating too — currently there are three call sites at lines 109–110, 137–138, and 288–289. A shared constant or helper would prevent future drift:

const installGhAwScript = `
  mkdir -p /tmp/gh-aw
  curl -fsSL "(redacted)" -o /tmp/gh-aw/install-gh-aw.sh
  echo "${GH_AW_INSTALL_SHA256}  /tmp/gh-aw/install-gh-aw.sh" | sha256sum -c -
  bash /tmp/gh-aw/install-gh-aw.sh
`

@copilot please address this.

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both generated workflow templates embed the same incomplete fix — mutable URL, no SHA256 — propagating the vulnerability to every downstream user repo.

💡 Impact and fix

The template at lines 108-110 (function return value) and the constant at lines 136-138 (copilotSetupStepsYAML) both emit:

run: |
  mkdir -p /tmp/gh-aw
  curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh -o /tmp/gh-aw/install-gh-aw.sh
  bash /tmp/gh-aw/install-gh-aw.sh

This is written into users' .github/workflows/copilot-setup-steps.yml. Unlike the fix applied to TruffleHog/Ollama (which only affects this repo's internal workflows), these templates multiply the risk to every external repository running gh aw init. Fixing the static copilot-setup-steps.yml in this repo but leaving these templates unfixed means the vulnerability is reintroduced every time a user regenerates their setup file.

Both the template function and the constant must be updated atomically. The template should either:

  1. Pin to an immutable release URL + emit a sha256sum -c - line, or
  2. Unconditionally use the already-correct uses: github/gh-aw-actions/setup-cli@SHA action path (the release/action mode at line ~88 does this correctly).

The current two-code-path design (dev mode using a script, release mode using an action) means this gap will re-appear on every dev-mode regeneration.

`, installRef)
}

// copilotSetupStepsYAML is a static dev-mode template used only for YAML validity tests.
// It deliberately uses the mutable branch ref as a fallback; the runtime function
// generateCopilotSetupStepsYAML resolves the ref to an immutable commit SHA whenever possible.
const copilotSetupStepsYAML = `name: "Copilot Setup Steps"

# This workflow configures the environment for GitHub Copilot Agent with gh-aw MCP server
Expand All @@ -131,7 +143,9 @@ jobs:
steps:
- name: Install gh-aw extension
run: |
curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh | bash
mkdir -p /tmp/gh-aw
curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh -o /tmp/gh-aw/install-gh-aw.sh
bash /tmp/gh-aw/install-gh-aw.sh
Comment on lines 143 to +148
`

// CopilotWorkflowStep represents a GitHub Actions workflow step for Copilot setup scaffolding
Expand Down Expand Up @@ -278,9 +292,17 @@ func renderCopilotSetupUpdateInstructions(ctx context.Context, filePath string,
fmt.Fprintln(os.Stderr, " with:")
fmt.Fprintln(os.Stderr, " version: "+version)
} else {
// Dev/script mode: try to resolve main to a pinned SHA so the instructions emit an
// immutable URL; fall back to the mutable branch ref if resolution is unavailable.
installRef := "refs/heads/main"
if sha, err := workflow.ResolveGhAwRef(ctx, "main"); err == nil && sha != "" {
installRef = sha
}
fmt.Fprintln(os.Stderr, " - name: Install gh-aw extension")
fmt.Fprintln(os.Stderr, " run: |")
fmt.Fprintln(os.Stderr, " curl -fsSL https://raw.githubusercontent.com/github/gh-aw/refs/heads/main/install-gh-aw.sh | bash")
fmt.Fprintln(os.Stderr, " mkdir -p /tmp/gh-aw")
fmt.Fprintln(os.Stderr, " curl -fsSL https://raw.githubusercontent.com/github/gh-aw/"+installRef+"/install-gh-aw.sh -o /tmp/gh-aw/install-gh-aw.sh")
fmt.Fprintln(os.Stderr, " bash /tmp/gh-aw/install-gh-aw.sh")
Comment on lines 301 to +305

@github-actions github-actions Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/codebase-design] The install script snippet is inlined as three separate fmt.Fprintln calls in the instructions renderer (lines 287–290) while the same snippet is a raw string literal in the workflow template constants above. These three copies will drift.

💡 Suggestion

Extract the install snippet to a single const or var used by both the template strings and the instructions renderer, so any future change (e.g., adding SHA256 verification) only needs to be made in one place.

@copilot please address this.

}
fmt.Fprintln(os.Stderr)
}
Expand Down