fix: updated dependencies

[varonix0]

Description 📣

Updated dependencies and bumped Go version to 1.25.8.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[greptile-apps]

Greptile Summary

This PR updates the Go toolchain version to 1.25.8 across all CI/CD workflows and module files (go.mod, e2e/go.mod), and refreshes several transitive and direct dependencies including golang.org/x/crypto, golang.org/x/oauth2, golang.org/x/sys, cloud.google.com/go/auth, go.opentelemetry.io/*, and notably bumps infisical/go-sdk from v0.6.8 to v0.7.0.

Key observations:

• The release_build_infisical_cli.yml workflow still uses actions/setup-go@v3 (while e2e tests use @v6 and CLI tests use @v4), which is inconsistent and may have reduced caching/toolchain support for Go 1.25.x.
• The go directive in go.mod and e2e/go.mod is pinned to the full patch version 1.25.8, which is more restrictive than the usual convention of specifying only the minor version (go 1.25) with a separate toolchain directive.
• The infisical/go-sdk minor version bump (v0.6.8 → v0.7.0) could contain breaking API changes; no corresponding source-code changes are present in this PR, suggesting the API surface used by the CLI is compatible, but this should be confirmed against the go-sdk changelog.

Confidence Score: 3/5

Generally safe dependency refresh, but the stale actions/setup-go@v3 in the release workflow and the overly specific go directive patch-pin warrant attention before merging.

The changes are mostly mechanical dependency and toolchain updates with no logic changes. Two non-critical style issues lower the score: the actions/setup-go@v3 inconsistency in the critical release workflow (could silently cause caching or resolution issues for Go 1.25.x), and the unconventional patch-level pinning of the go directive in go.mod. The go-sdk minor bump is low-risk if no code changes were needed, but should be verified against the SDK changelog.

.github/workflows/release_build_infisical_cli.yml (outdated actions/setup-go@v3 action in both release jobs) and go.mod / e2e/go.mod (patch-level go directive).

Important Files Changed

Filename	Overview
.github/workflows/release_build_infisical_cli.yml	Go version bumped to 1.25.8 in both goreleaser jobs, but the action remains at actions/setup-go@v3 which is much older than the @v6 used in e2e tests and could have compatibility or caching issues.
.github/workflows/run-cli-e2e-tests.yml	Go version updated from 1.25.2 to 1.25.8 across all three e2e test jobs using the up-to-date actions/setup-go@v6 — straightforward, no issues.
.github/workflows/run-cli-tests.yml	Go version updated from 1.21.x to 1.25.8 — large jump but consistent with the rest of the PR and no other concerns.
go.mod	Go toolchain directive updated to 1.25.8 and infisical/go-sdk bumped from v0.6.8 to v0.7.0 (minor version bump — potential for breaking changes).
e2e/go.mod	Go version directive and several cloud/google, opentelemetry, and golang.org/x/* dependencies updated to newer versions; no obvious issues beyond the SDK minor bump.
go.sum	Checksums updated to match the new dependency versions — expected mechanical change.
e2e/go.sum	Checksums updated to match the new dependency versions — expected mechanical change.

_{Reviews (1): Last reviewed commit: "fix: updated dependencies" | Re-trigger Greptile}

[greptile-apps]

go directive set to a specific patch version

Setting the go directive to a specific patch version (1.25.8) means any Go toolchain older than 1.25.8 cannot build this module. This is more restrictive than necessary — typical convention is to set the minimum minor version (e.g., go 1.25) and let the toolchain directive (or CI) pin the exact patch. If pinning a patch is intentional for reproducibility, consider adding an explicit toolchain go1.25.8 directive alongside go 1.25 to make the intent clearer.

Suggested change

	go 1.25.8
	go 1.25
	toolchain go1.25.8

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[varonix0]

@greptile there's a cve in younger versions, so it needs to be >=1.25.8. i don't think there's anything else we can do?

[greptile-apps]

You're absolutely right — if there's a CVE in versions <1.25.8, then go 1.25.8 is the correct approach. It enforces the minimum patch version, which is exactly what you need here.

My original suggestion about splitting it into go 1.25 + toolchain go1.25.8 wouldn't work for your use case because go 1.25 would still allow vulnerable versions like 1.25.0-1.25.7.

One optional improvement: consider adding a comment above the go directive to document the CVE requirement, so future maintainers understand why a specific patch version is pinned:

Suggested change

	go 1.25.8
	// Requires Go 1.25.8+ due to CVE in earlier versions
	go 1.25.8

But the directive itself is correct as-is.