Bump Go to 1.25.3

[github-actions]

This PR updates Go to the latest stable release.

• go directive: 1.25.0
• toolchain: 1.25.3

Other changes:

• All docs pointing to Go version are updated.
• Devcontainer dependency on Go is updated and tested in Codespaces.
• An old backport of strings.CutSuffix is now dropped in favour of stdlib implementation.

The reported vulnerabilities (e.g. here) are false positives. It's because govluncheck thinks we're importing the latest untagged cli/cli as an external dependency.

[babakks]

This was an intact copy/paste of the stdlib implementation (below), so it's safe to just use the stdlib now:

func CutSuffix(s, suffix string) (before string, found bool) {
	if !HasSuffix(s, suffix) {
		return s, false
	}
	return s[:len(s)-len(suffix)], true
}

[Copilot]

Pull Request Overview

This PR upgrades the project's Go version requirement from 1.24 to 1.25 and removes a custom cutSuffix backport function in favor of using the standard library's strings.CutSuffix.

• Upgrades Go version from 1.24 to 1.25 in go.mod
• Replaces custom cutSuffix function with strings.CutSuffix from the standard library
• Updates documentation and development environment configurations to reflect the new Go version requirement

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/ghinstance/host.go	Removes custom cutSuffix backport function and uses strings.CutSuffix
go.mod	Updates Go version to 1.25.0 and toolchain to go1.25.3
docs/source.md	Updates documentation to require Go 1.25+
docs/install_source.md	Updates installation instructions to require Go 1.25+
.github/CONTRIBUTING.md	Updates contributor prerequisites to require Go 1.25+
.devcontainer/devcontainer.json	Updates dev container image to use Go 1.25

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[BagToad]

Actually, I think there are issues with this branch. Govulncheck is failing 🤔

[babakks]

Yeah, I've noticed them. Already touched on this in the body:

The reported vulnerabilities (e.g. here) are false positives. It's because govluncheck thinks we're importing the latest untagged cli/cli as an external dependency.

[babakks]

@BagToad, I think I reproduced this by shallow cloning the repo (--depth 1) and running govulncheck on the binary (expand below). This is what happens in our CI. govulncheck compalins because it doesn't know the actual version of the binary it's testing. So, I think we're okay.

Details

➜  cli git:(trunk) govulncheck ./...
No vulnerabilities found.
➜  cli git:(trunk) make
GOOS= GOARCH= GOARM= GOFLAGS= CGO_ENABLED= go build -o script/build script/build.go
go build -trimpath -ldflags "-X github.com/cli/cli/v2/internal/build.Date=2025-11-03 -X github.com/cli/cli/v2/internal/build.Version=cd9e5e5 " -o bin/gh ./cmd/gh
➜  cli git:(trunk) govulncheck -mode binary ./bin/gh
=== Symbol Results ===

Vulnerability #1: GO-2024-3310
    Downloading malicious GitHub Actions workflow artifact results in path
    traversal vulnerability in github.com/cli/cli
  More info: https://pkg.go.dev/vuln/GO-2024-3310
  Module: github.com/cli/cli/v2
    Found in: github.com/cli/cli/v2@v2.0.0-20251101001944-cd9e5e534fc0
    Fixed in: github.com/cli/cli/v2@v2.63.1
    Vulnerable symbols found:
      #1: accessibility.NewCmdAccessibility
      #2: actions.NewCmdActions
      #3: add.NewCmdAdd
      #4: add.NewCmdAdd
      #5: add.NewCmdAdd
      Use '-show traces' to see the other 1518 found symbols

Vulnerability #2: GO-2024-3296
    Recursive repository cloning can leak authentication tokens to non-GitHub
    submodule hosts in github.com/cli/cli
  More info: https://pkg.go.dev/vuln/GO-2024-3296
  Module: github.com/cli/cli/v2
    Found in: github.com/cli/cli/v2@v2.0.0-20251101001944-cd9e5e534fc0
    Fixed in: github.com/cli/cli/v2@v2.63.0
    Vulnerable symbols found:
      #1: accessibility.NewCmdAccessibility
      #2: actions.NewCmdActions
      #3: add.NewCmdAdd
      #4: add.NewCmdAdd
      #5: add.NewCmdAdd
      Use '-show traces' to see the other 1518 found symbols

Vulnerability #3: GO-2024-3269
    Connecting to a malicious Codespaces via GH CLI could allow command
    execution on the user's computer in github.com/cli/cli
  More info: https://pkg.go.dev/vuln/GO-2024-3269
  Module: github.com/cli/cli/v2
    Found in: github.com/cli/cli/v2@v2.0.0-20251101001944-cd9e5e534fc0
    Fixed in: github.com/cli/cli/v2@v2.62.0
    Vulnerable symbols found:
      #1: accessibility.NewCmdAccessibility
      #2: actions.NewCmdActions
      #3: add.NewCmdAdd
      #4: add.NewCmdAdd
      #5: add.NewCmdAdd
      Use '-show traces' to see the other 1518 found symbols

Your code is affected by 3 vulnerabilities from 1 module.
This scan found no other vulnerabilities in packages you import or modules you
require.
Use '-show verbose' for more details.

[BagToad]

@babakks oh wow good catch! I'm a bit confused because won't this happen in every PR CI run if we merge this? I suspect the answer is "no" and we're good to merge this, but do you know? My gut tells me this is going to happen on every CI run, but then again this shallow clone is there in trunk too, so I don't know why it's only causing an issue now in this PR.

[BagToad]

BTW, should we bump Go in go-gh too?

[BagToad]

Update from @babakks and I discussing this more:

It looks like the vcs stamp is now different in Go 1.25 when built with a shallow clone. It now drops the minor and patch versions v2.xx.xx and instead uses an arbitrary v2.0.0 causing govulncheck to think we are building gh with vulnerabilities discovered and fixed between v2.0.0 and the latest v2.85.x. We're not sure why exactly this changed.

Setting buildvcs to false fixes the issue because that version information doesn't get stamped into the binary, but that's probably not a great fix.

We also noticed that scanning in source code mode instead of binary mode fixes the issue, probably because the source code scan can resolve the real versions.

At one point I changed the govulncheck.yml from binary scanning to source code scanning to fix our code scanning alerts and configuration, since scanning in binary mode does not include the line number information that GitHub Code Scanning requires.

That said, a safe change is to update the liny.yml workflow to also scan in source code mode, as this was likely an oversight on my part anyway when I proposed we update the govulncheck workflow.

Additionally, we can also leverage code scanning for the lint workflow by exporting the SARIF file, enabling rich line annotations for govulncheck findings directly in PRs down the line.