[GayatriNairAtBrowserstack]

Update (9cecf69): go.mod directive raised to go 1.27.3, so stacks on Go 1.27.0-1.27.2 also switch to a patched toolchain. Re-verified with go1.27.3: go build, go vet, go test ./... pass; binary reports go1.27.3. Figures below are from the earlier 1.26.10 run; the auto-switch / fail-closed behaviour is the same with 1.27.3 as the floor.

Jira: https://browserstack.atlassian.net/browse/AAP-22023

What

• go.mod: go 1.18 -> go 1.26.10. go mod tidy moved tablewriter and testify from indirect to direct requires and dropped unused objx. No dependency versions changed. No toolchain line: it equals the go directive, so tidy removes it.
• main.go, util_fns.go: 8 calls failf(err.Error()) -> failf("%s", err.Error()). At language version >= 1.24, the go vet printf check flags non-constant format strings, and go test runs vet, so tests failed without this. Behaviour is unchanged, except that a % inside an error message is no longer misformatted.

Why

Go releases before 1.26.10 / 1.27.3 do not distrust the 8 compromised eMudhra intermediate keys. This step sends BrowserStack credentials to api-cloud.browserstack.com from customer CI. In go1.26.10, crypto/x509 has distrustedSPKIHashes (8 entries). Both Verify (verify.go) and the macOS platform-verifier path (root_darwin.go) enforce it. Local go1.26.4 does not have it.

How it reaches customers

The Bitrise go toolkit (toolkit: go in step.yml, stepman v0.27.0 as vendored in bitrise CLI master) works like this:

• It picks the go on PATH if it is >= 1.22.12. Otherwise it installs go1.22.12.
• It runs go build -o <bin> with GO111MODULE=on. It does not set GOTOOLCHAIN, so the default auto applies.
• With go 1.26.10 in go.mod, the stack Go (>= 1.21) downloads and uses go1.26.10. No step.yml change is needed, and step.yml has no Go version field (GoStepToolkitModel has only package_name).
• If a build environment sets GOTOOLCHAIN=local, or blocks the golang.org/toolchain module download, the build fails with go.mod requires go >= 1.26.10. It does not fall back to an older Go.
• The toolkit caches the compiled binary per step version, so customers get the fix only from a new step version.

Verification (local, darwin/arm64)

• go version: go1.26.4 (local). GOTOOLCHAIN=go1.26.10 go version: go1.26.10.
• go mod tidy: rc=0
• go build ./...: rc=0
• go vet ./...: rc=0 (before the failf fix: 8 non-constant format string in call to ...failf, at main.go:38,48,54,66,72,82,102 and util_fns.go:127)
• go test ./...: ok github.com/browserstack/browserstack-bitrise-xcui-step 3.533s
• go version -m on the binary: go1.26.10
• GOTOOLCHAIN=local go build ./... with go1.26.4: go: go.mod requires go >= 1.26.10 (running go 1.26.4; GOTOOLCHAIN=local)
• Baseline on main (go 1.18 directive, go1.26.10 toolchain): vet rc=0, tests ok.

Notes: io/ioutil (deprecated, still works) is left unchanged to keep this diff minimal.

Release steps still needed

1. Run the step on a real Bitrise macOS stack. Confirm in the build log that the binary is compiled with go1.26.10 (toolchain auto-download).
2. Merge, then tag a new step version (latest tag is 1.0.1). Bump BITRISE_STEP_VERSION in bitrise.yml as needed.
3. Run bitrise run share-this-step and open the bitrise-steplib PR.
4. Tell customers to move to the new version. Pinned older versions (go 1.18 directive) keep building with whatever Go the stack has, which may be older than 1.26.10.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Central YAML (base), Organization UI (inherited), Workspace UI (inherited)
• Review profile: ASSERTIVE
• Plan: Enterprise
• Run ID: 9ad620b3-798a-47d2-99ea-4800bd99c212

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}