feat: enable checksum validation by default in install-gh-aw.sh#29223
Merged
Conversation
- Change SKIP_CHECKSUM default from true to false in both install-gh-aw.sh and actions/setup-cli/install.sh - Remove redundant SKIP_CHECKSUM=false in GitHub Actions context block (no longer needed since it's now the default) - Update header comments to reflect checksums are validated by default Agent-Logs-Url: https://github.com/github/gh-aw/sessions/73f24b82-4807-40b8-a61b-c662ee683ab0 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Copilot created this pull request from a session on behalf of
pelikhan
April 30, 2026 00:55
View session
Replace `grep "$EXPECTED_FILENAME" | awk '{print $1}'` with
`awk -v f="$EXPECTED_FILENAME" '$2 == f {print $1}'` to avoid
false matches when the filename appears as a substring in another
entry (e.g. matching 'gh-aw-linux-amd64-extra.tar.gz' when
searching for 'linux-amd64').
Agent-Logs-Url: https://github.com/github/gh-aw/sessions/057dcad8-6129-46c2-8ce5-d318e1698526
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Found one bug: the checksum lookup used Fixed in d4d43bb by replacing it with Everything else in the checksum path looks solid:
|
Contributor
There was a problem hiding this comment.
Pull request overview
Enables SHA256 checksum validation by default in the gh-aw installer scripts now that checksums.txt is consistently published with releases.
Changes:
- Flip default
SKIP_CHECKSUMfromtrue→falsein both install scripts. - Remove the GitHub Actions-only
SKIP_CHECKSUM=falseoverride (now redundant). - Tighten checksum lookup to an exact filename match using
awk(instead of substringgrep).
Show a summary per file
| File | Description |
|---|---|
| install-gh-aw.sh | Enables checksum verification by default and improves checksum lookup precision. |
| actions/setup-cli/install.sh | Mirrors the same default checksum behavior and checksum lookup update for the GitHub Action installer. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comments suppressed due to low confidence (1)
install-gh-aw.sh:16
- Header docs still reference
./install.shfor usage/examples, but this script isinstall-gh-aw.sh(and later messaging already uses that name). This can mislead users copy/pasting the examples; update the Usage/Examples lines here to match the actual filename.
# Usage: ./install.sh [version] [options]
#
# Examples:
# ./install.sh # Install latest version
# ./install.sh v1.0.0 # Install specific version
# ./install.sh --skip-checksum # Skip checksum validation
#
- Files reviewed: 2/2 changed files
- Comments generated: 0
Collaborator
|
@copilot investigate failure at https://github.com/github/gh-aw/actions/runs/25141957823/job/73694097432 |
The binary download and checksums download curl calls had no timeout options, causing them to hang indefinitely if a connection stalled. This was most visible on Windows GitHub Actions runners where the CI job ran for 3 hours before being killed. Add --connect-timeout 15 --max-time 120 to the binary download and --connect-timeout 15 --max-time 60 to the checksums download so the retry loop can cycle and eventually fail with a clear error instead of hanging forever. Agent-Logs-Url: https://github.com/github/gh-aw/sessions/1b540671-88f4-4de1-a709-01352e1f5788 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
The Windows job ran for ~3 hours before being killed by the runner. Root cause: the two Fixed in e5b1ac6 by adding:
This was a latent bug that became newly reachable for the checksums path once we flipped the |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Collaborator
|
@copilot add a 5 minute timeout on the jobs for the installation scripts test. Investigate why this one gets stuck: https://github.com/github/gh-aw/actions/runs/25191069497/job/73860917300?pr=29223 |
…30s timeout The Windows CI job was hanging in the install script at the binary verification step (lines 376/399): `"$BINARY_PATH" --help` and `"$BINARY_PATH" version` can stall indefinitely while Windows Defender scans the newly downloaded executable. - .github/workflows/install.yml: add `timeout-minutes: 5` to the test-install job so a hung Windows runner is killed in under 5 minutes instead of consuming the full runner quota (previously 3+ hours) - install-gh-aw.sh / actions/setup-cli/install.sh: set BINARY_EXEC_TIMEOUT to `timeout 30` on Windows, wrap both binary verification calls with it; on timeout emit a warning and continue rather than failing the install (the binary has already passed checksum verification so it is safe to use) Agent-Logs-Url: https://github.com/github/gh-aw/sessions/9be8cef1-6312-4362-a598-ab4c831a4838 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Root cause found: the install script executes Fixed in
|
… upgrade Agent-Logs-Url: https://github.com/github/gh-aw/sessions/4c934438-5f8d-40b7-a3cf-0723c85a02e0 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Agent-Logs-Url: https://github.com/github/gh-aw/sessions/4c934438-5f8d-40b7-a3cf-0723c85a02e0 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Root cause identified and fixed in Two separate bugs triggered the failure:
Also added Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Collaborator
Agent-Logs-Url: https://github.com/github/gh-aw/sessions/2f42f379-7c9d-4bf8-b428-8923ea3dcf67 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Root cause: the test installs Once |
Collaborator
…ady up to date' issue Agent-Logs-Url: https://github.com/github/gh-aw/sessions/fff7c9d0-800b-4c6e-91fe-dfd61ebaa6e3 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Root cause: the compatibility workaround ran correctly and detected Fixed in |
Collaborator
…old binaries Agent-Logs-Url: https://github.com/github/gh-aw/sessions/9eb70acf-45e1-4678-9cf5-12153842f0b7 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Root cause: Windows job running the old v0.71.2 binary. When The v0.71.3 Fixed in |
…n job The `gh api --jq` flag does not support `--arg` (a standalone jq flag). When `--jq --arg job_prefix "..." '.jobs...'` was parsed, `--arg` became the jq expression and the remaining tokens were treated as extra positional args to `gh api`, which only accepts one → "accepts 1 arg(s), received 4". Fix: pipe `gh api` output to `jq -r --arg ...` in both places: - Conclusion job: Collect upgrade test outcomes step - upgrade-path-test: Find target and previous releases step (release path) Agent-Logs-Url: https://github.com/github/gh-aw/sessions/09c4e026-cd78-4599-869d-66c2a1fa6f54 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Collaborator
|
@copilot merge main and recompile |
…validation-install-gh-aw Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Contributor
Author
Done in Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Enable SHA256 checksum validation by default when installing the gh-aw binary, and fix several latent issues that became reachable once checksum validation runs on every install.
Background
scripts/build-release.shalready generates achecksums.txtfile during the build process, and the release workflow uploads alldist/*files (includingchecksums.txt) to every GitHub release. The validation logic in both install scripts was fully implemented but gated behindSKIP_CHECKSUM=true(the default), pending checksums being available in releases.Since checksums are now consistently published, this PR flips the default to
SKIP_CHECKSUM=false.Changes
Install scripts (
install-gh-aw.sh/actions/setup-cli/install.sh)SKIP_CHECKSUM=true→SKIP_CHECKSUM=false; remove redundantSKIP_CHECKSUM=falseoverride in the GitHub Actions context block; update header commentgrep "$EXPECTED_FILENAME" | awk '{print $1}'(substring match) withawk -v f="$EXPECTED_FILENAME" '$2 == f {print $1}'(exact field match) to prevent false positives--connect-timeout 15 --max-time 120/60tocurlcalls to prevent indefinite hangs when connections stall on Windows runnersBINARY_EXEC_TIMEOUT="timeout 30"on Windows wrapping the post-install binary verification calls (--help,version), matching the existing pattern forgh extension install; on timeout a warning is emitted and the install completes (the binary already passed checksum verification).github/workflows/install.ymltimeout-minutes: 5to thetest-installjob so hung Windows runners are cancelled quicklyversion,--help) withtimeout 60on Windows, preventing the step itself from hanging after the install script completespkg/cli/update_extension_check.gogh extension upgrade --forceresolves the upgrade target via/releases/latestwhich excludes prereleases; on macOS the binary is not locked so the first attempt "succeeds" but installs an older stable release instead of the desired prerelease. When--pre-releasesis set on macOS, skipgh extension upgrade --forceentirely and usegh extension remove+gh extension install --pin <latestVersion>to ensure the exact version is installed.os.Rename(backup, os.TempDir()+...)which fails with EXDEV when the extension directory (C:) and%TEMP%(D:) are on different drives — common on GitHub Actions runners. Added a same-drive fallback that moves the backup to the parent of the extension directory, which is guaranteed to be on the same drive..bakcleanup): TheghCLI has its own Windows rename-and-retry mechanism that creates{exe}.{pid}.bakfiles. If such a file is left behind and briefly locked by Windows Defender after the originating process exits,gh extension upgrade --forcefails with "failed to remove previous extension update state: Access is denied". AddedcleanupStaleWindowsBackups()— called after our own backup is relocated — which retries removal of any foreign.bakfiles in the extension directory with short delays to outlast transient antivirus locks. Added"failed to remove previous extension update state"toisWindowsLockErrorso the Windows manual-upgrade guidance is shown when theghCLI surfaces this message..github/workflows/upgrade-test.ymlgh extension upgrade --forceon macOS and may install the latest stable release instead of the target prerelease. Added a post-upgrade check on macOS: if the installed version does not match the expected prerelease, log a warning and correct viagh extension install --pin <target>so the version verification step can still confirm the target works correctly.Testing
bash -nsyntax check passes on both scriptsscripts/test-install-script.sh— all 10 test groups passpkg/cli/passcleanupStaleWindowsBackupsand the newisWindowsLockErrorpattern