CircleCI-Public / CircleCI-Public/gcp-cli-orb

install: hardcoded -x86_64 download URL installs a wrong-architecture SDK on arm64 runners

Open Beginner friendly
#103 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
10
Forks
34
PR merge metrics
No merged PRs in 30d

Description

## My description
Switching from gsutil to gcloud storage failed on download of my files step on arm mac
AI helped me with more details:

## Summary

`install.sh` detects the OS with `uname -s` but never checks the machine
architecture, and hardcodes `-x86_64` into the download URL. On any arm64
runner it therefore installs an x86_64 Google Cloud SDK.

## Affected versions

Confirmed in **v3.3.2** and **v4.0.1** (latest). The hardcoded suffix was
carried through the 3.x → 4.x major bump unchanged.

## Root cause

https://github.com/CircleCI-Public/gcp-cli-orb/blob/v4.0.1/src/scripts/install.sh#L95

```sh
curl --location --silent --fail --retry 3 --output "$output_file" \
"https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-$url_path_fixture-$version-$platform-x86_64.tar.gz"
```

`$platform` comes from the only detection block in the script (L132-L139),
which switches on `uname -s` alone:

```sh
unameOut="$(uname -s)"
case "${unameOut}" in
Linux*) platform=linux;;
Darwin*) platform=darwin;;
...
```

`uname -m`, `arm64` and `aarch64` do not appear anywhere in the script.

Google does publish per-architecture archives at the same URL pattern — note
the suffix is `-arm`, not `-arm64`/`-aarch64`:

```
200 google-cloud-cli-576.0.0-darwin-arm.tar.gz
200 google-cloud-cli-576.0.0-linux-arm.tar.gz
200 google-cloud-cli-576.0.0-darwin-x86_64.tar.gz
404 google-cloud-cli-576.0.0-darwin-arm64.tar.gz
```

## Impact

The install itself appears to succeed, so the failure surfaces later and is
hard to trace back to the orb. On macOS Apple Silicon runners the bundled
`gcloud-crc32c` helper cannot execute, and every `gcloud storage` transfer
fails:

```
Copying gs://example-bucket/path/artifact.zip to file:///Users/distiller/project/artifact.zip
ERROR: [Errno 86] Bad CPU type in executable: '/private/var/folders/.../T/tmp.XXXXXXXX/google-cloud-sdk/bin/gcloud-crc32c'
ERROR: [Errno 86] Bad CPU type in executable: '/private/var/folders/.../T/tmp.XXXXXXXX/google-cloud-sdk/bin/gcloud-crc32c'
ERROR: Task 4433508544 failed: Failed to download one or more component of sliced download.
```

This affects CircleCI's own arm resource classes — macOS Apple Silicon
(e.g. `m4pro.medium`) and Linux `arm.*`.

It has likely gone unnoticed because `gsutil` used a pure-Python CRC32C
implementation and never invoked the helper binary. Now that `gsutil` is
deprecated in favour of `gcloud storage`, anyone migrating on an arm runner
will hit this.

## Reproduction

```yaml
executor:
macos:
xcode: 26.6
resource_class: m4pro.medium
steps:
- gcp-cli/install:
version: 576.0.0
- run: file "$(gcloud info --format='value(installation.sdk_root)')/bin/gcloud-crc32c"
# => Mach-O 64-bit executable x86_64, on an arm64 host
- run: gcloud storage cp gs://some-bucket/some-object .
# => ERROR: [Errno 86] Bad CPU type in executable
```

## Expected

The orb installs the SDK build matching the host architecture.

## Suggested fix

```diff
unameOut="$(uname -s)"
case "${unameOut}" in
Linux*) platform=linux;;
Darwin*) platform=darwin;;
CYGWIN*) platform=windows;;
MINGW*) platform=windows;;
MSYS_NT*) platform=windows;;
*) platform="UNKNOWN:${unameOut}"
esac
+
+# Google suffixes the arm archives "-arm", not "-arm64"/"-aarch64".
+machineOut="$(uname -m)"
+case "${machineOut}" in
+ x86_64|amd64) arch=x86_64;;
+ arm64|aarch64) arch=arm;;
+ *) arch="UNKNOWN:${machineOut}"
+esac
```

```diff
output_file="$install_directory/google-cloud-sdk.tar.gz"
- curl --location --silent --fail --retry 3 --output "$output_file" "https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-$url_path_fixture-$version-$platform-x86_64.tar.gz"
+ curl --location --silent --fail --retry 3 --output "$output_file" "https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-$url_path_fixture-$version-$platform-$arch.tar.gz"
tar -xzf "$output_file" -C "$install_directory"
```

The Windows branch is left on `x86_64`, since Google does not publish an arm
archive for it.

## Workaround

For anyone hitting this before a fix lands, forcing gcloud off the helper
binary avoids the crash without changing the SDK:

```sh
export CLOUDSDK_STORAGE_USE_GCLOUD_CRC32C=False
export CLOUDSDK_STORAGE_SLICED_OBJECT_DOWNLOAD_THRESHOLD=0
```

Downloads then validate against the object's MD5 instead of CRC32C.

Contributor guide

No contributing guide indexed for this repository

Research direction

Read src/scripts/install.sh around the platform detection and download URL, then reproduce the install on an arm runner using the commands in the issue. Verify that the downloaded archive and gcloud-crc32c match the host architecture and that gcloud storage completes without the Bad CPU type error.

Written by the indexing model from the issue text.

Assessment

Tech stack
google-cloud, shell
Domain
cli, cloud, devops
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
82/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.