Repository navigation
fix(deps): bump Go to 1.26.4 and x/net to v0.55.0 to close OSV advisories - #2852
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses 12 security advisories identified by the OpenSSF Scorecard and OSV scanner. By upgrading the Go toolchain and updating specific networking dependencies, the project has successfully cleared its vulnerability scan results while maintaining build and generation integrity. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughGo toolchain directives bumped from 1.26.2 to 1.26.4 in ChangesGo Toolchain and Dependency Maintenance
🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs:
Suggested reviewers:
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the Go version from 1.26.2 to 1.26.4 and bumps several golang.org/x dependencies in the main module. A security-related review comment points out that the api/apps/v1alpha1 submodule still uses a vulnerable version of golang.org/x/net (v0.53.0) as an indirect dependency, and recommends upgrading it to v0.55.0 to address known vulnerabilities.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| module github.com/cozystack/cozystack/api/apps/v1alpha1 | ||
|
|
||
| go 1.26.2 | ||
| go 1.26.4 |
There was a problem hiding this comment.
The api/apps/v1alpha1 submodule still uses golang.org/x/net v0.53.0 as an indirect dependency, which is vulnerable to GO-2026-4918 and GO-2026-5026. To fully resolve these advisories across the repository, update golang.org/x/net to v0.55.0 in api/apps/v1alpha1/go.mod as well by running go get golang.org/x/[email protected] and go mod tidy inside the api/apps/v1alpha1 directory.
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
NOT LGTM — the api/apps/v1alpha1 submodule still ships golang.org/x/net v0.53.0, which remains affected by GO-2026-5026, so the PR does not fully close the OSV set it targets.
Business context: clear the OpenSSF Scorecard Vulnerabilities check by closing the OSV advisories that osv-scanner surfaces over both go.mod files (10 stdlib via the Go toolchain bump, 2 in golang.org/x/net).
Blockers
B1: submodule api/apps/v1alpha1 left on vulnerable x/net v0.53.0
File: api/apps/v1alpha1/go.mod
Issue: the PR bumps the go directive to 1.26.4 in the submodule but leaves golang.org/x/net at v0.53.0; only the root module is raised to v0.55.0.
Evidence: osv.dev reports GO-2026-5026 (golang.org/x/net/idna, failure to reject ASCII-only Punycode-encoded labels) with range introduced: 0, fixed: 0.55.0, so v0.53.0 is affected. The submodule's import graph includes golang.org/x/net/idna (go list -deps ./...) — the exact package the advisory names. There is no go.work, and the root module does not require the submodule, so MVS does not lift it to v0.55.0; it is scanned and built as an independent module at v0.53.0. The "osv-scanner: 0 vulnerabilities" verification therefore does not hold for the submodule. GO-2026-4918, the other x/net advisory, is fixed in 0.53.0 and is correctly closed.
Impact: Scorecard's Vulnerabilities check scans every go.mod in the repo, so GO-2026-5026 stays open against the submodule and the check will not reach 10/10 — the PR's stated goal is not met.
Fix: bump x/net in the submodule as well — cd api/apps/v1alpha1 && go get golang.org/x/[email protected] && go mod tidy — then re-run osv-scanner over both modules to confirm 0 advisories.
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — the api/apps/v1alpha1 submodule is now on golang.org/x/net v0.55.0, closing GO-2026-5026, so the OSV set is fully cleared across both modules.
Business context: clear the OpenSSF Scorecard Vulnerabilities check by closing the OSV advisories that osv-scanner surfaces over both go.mod files (10 stdlib via the Go toolchain bump, 2 in golang.org/x/net).
Resolved: the submodule moved from x/net v0.53.0 to v0.55.0, which closes GO-2026-5026 (golang.org/x/net/idna, the package the submodule imports); the root module was already on v0.55.0, and both modules build clean. With the Go directive at 1.26.4 in both modules (the 10 stdlib advisories) and x/net at v0.55.0 in both (GO-2026-4918, fixed in 0.53.0, and GO-2026-5026, fixed in 0.55.0), no OSV advisory remains across the dependency graph.
…ries Clears the OpenSSF Scorecard Vulnerabilities check (was 0/10). An osv-scanner pass over both go.mod files reported 12 advisories: - 10 stdlib advisories against the Go toolchain pinned at 1.26.2 (GO-2026-4918/4971/4977/4980/4982/4986 fixed in 1.26.3; GO-2026-5037/5038/5039 fixed in 1.26.4) — closed by raising the go directive to 1.26.4 in both the root module and api/apps/v1alpha1. - golang.org/x/net 0.52.0 (GO-2026-4918, GO-2026-5026) — bumped to v0.55.0; go mod tidy carried the matching x/crypto, x/sys, x/term, x/text and x/tools minor bumps via MVS. After the bump osv-scanner reports 0 advisories. Both modules build, and 'make generate' produces no drift (codegen-drift stays green). Versions were changed with 'go mod edit'/'go get'/'go mod tidy', not by hand-editing the generated go.mod. Signed-off-by: Myasnikov Daniil <[email protected]> Assisted-By: Claude <[email protected]>
…odule The submodule still pulled golang.org/x/net v0.53.0, affected by GO-2026-5026 (failure to reject ASCII-only Punycode-encoded labels in golang.org/x/net/idna, which the submodule imports). The root module was already on v0.55.0; align the submodule so the advisory is closed across both go.mod files. Assisted-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>
c337915 to
d739663
Compare
#3019) ## What this PR does Restores the OpenSSF Scorecard **Vulnerabilities** check to green. It regressed to **0/10** after #2852: in the weeks since, `golang.org/x/crypto v0.51.0` accrued **13 new advisories** (`GO-2026-5005`, `5006`, `5013`–`5021`, `5023`, `5033`). An `osv-scanner` pass over `main` confirmed all 13 trace to that single package. ### Change - **`golang.org/x/crypto 0.51.0 → 0.52.0`** (the fixed version for all 13). No transitive cascade — `go mod tidy` changed only this line plus its two `go.sum` hashes. Bumped with `go get` / `go mod tidy`, not by hand-editing the generated `go.mod`. ### Verification - `osv-scanner` after the bump: **No issues found** (0 advisories across both modules). - `go build ./...` passes. - `make generate` produces **no drift** — `codegen-drift` stays green. > Scorecard's report mentioned advisory IDs as low as `GO-2025-3512` (kubevirt-csi, CVE-2024-1725). That package is **not** in `go.mod` or `go.sum` — it isn't a cozystack dependency, so nothing to bump there. The real cluster is the 13 x/crypto advisories this PR closes. ### Why this keeps happening (and the durable fix) `x/crypto` is an **indirect** dependency, and the Renovate app isn't actually opening PRs on this repo yet (no `renovate[bot]` PRs, no Dependency Dashboard) — the org Renovate install needs `cozystack/cozystack` added to its repo list. Until then, indirect-dep and Go-toolchain advisories will keep knocking this check back to 0 and need manual bumps like this one. Recommended follow-ups: enable Renovate on the repo, and allow it to bump indirect deps (and optionally the Go patch version). ### Release note ```release-note fix(deps): bump golang.org/x/crypto to v0.52.0, closing 13 known OSV advisories (GO-2026-5005…5033) ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated cryptographic dependency to the latest patch version for enhanced security and stability. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Restores the OpenSSF Scorecard Vulnerabilities check to green. It regressed to 0/10 after cozystack#2852 because golang.org/x/crypto v0.51.0 accrued 13 new advisories (GO-2026-5005, 5006, 5013-5021, 5023, 5033). osv-scanner confirms all 13 trace to that one indirect package; v0.52.0 is the fixed version. go mod tidy changed only this line and its two go.sum hashes. After the bump osv-scanner reports no issues, both modules build, and 'make generate' produces no drift. Versions were changed with go get / go mod tidy, not by hand-editing the generated go.mod. Signed-off-by: Myasnikov Daniil <[email protected]> Assisted-By: Claude <[email protected]>
…#2941) ## What this PR does Completes the Go-toolchain modernization for first-party images — the build-time counterpart to #2852, which raised the root and `api/` modules to Go 1.26.4. 1. **First-party image Go modules → go 1.26.4** (`token-proxy`, `kube-ovn-webhook`, `kubevirt-csi-driver`): raise the `go` directive and refresh dependencies. `kube-ovn-webhook` moves `k8s.io/*` 0.26 → 0.36.2 (only long-stable admission/core API is used); `kubevirt-csi-driver` keeps its existing replace-based k8s alignment at 0.36.0 (main's refactor owns that module's pin) and raises the `go` directive, with the `golang.org/x/net` 0.56.0 security bump — which clears the reachable GO-2026-5026 — reapplied. Adds two `.gitignore` files so the locally-built binaries can't be committed. 2. **Go builder images → `golang:1.26`** across 8 images still on EOL/behind toolchains (golang 1.20, 1.20.6, 1.23.4, 1.24, 1.25): `cluster-autoscaler`, `kubevirt-cloud-provider`, `redis-operator`, `multus-cni`, `keycloak-operator`, `objectstorage`, `kilo`, `linstor-csi`. The builder image tag — not the go.mod minimum — sets the standard-library version baked into the binary, so these still shipped unpatched stdlib on a plain rebuild. Verified: `GOOS=linux go build`/`go vet` pass for all three modules and `go mod tidy` is a no-op; the three biggest builder jumps (redis-operator, kubevirt-cloud-provider, cluster-autoscaler — all formerly Go 1.20.x/1.23.x) were verified with a local `docker build`; the remaining five (1.24/1.25 → 1.26) are covered by CI image builds. ### Release note ```release-note chore(platform): raise the Go toolchain to 1.26 across first-party images to clear standard-library security advisories ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated several container build environments to a newer Go release for consistency across Kubernetes-related components. * Refreshed module and dependency versions in a few services to keep builds current. * Expanded ignore rules for generated image artifacts so build outputs aren’t tracked. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
What this PR does
Clears the OpenSSF Scorecard Vulnerabilities check (was 0/10). Scorecard queries OSV against the dependency graph, so reproducing it with
osv-scannerover bothgo.modfiles surfaced 12 advisories:golang.org/x/net10 of 12 are stdlib advisories against the Go toolchain pinned at
1.26.2— so the dominant fix is raising the Go directive, not churning dependencies.Changes
1.26.2 → 1.26.4in the root module and theapi/apps/v1alpha1submodule (closes all 10 stdlib advisories; 1.26.4 is required for GO-2026-5037/5038/5039).golang.org/x/net 0.52.0 → 0.55.0(closes GO-2026-4918, GO-2026-5026).go mod tidycarried the matching minor bumps tox/crypto,x/sys,x/term,x/text,x/toolsvia MVS.All version changes were made with
go mod edit/go get/go mod tidy— the generatedgo.modwas not hand-edited.Verification
osv-scannerafter the bump: Total 0 packages affected by 0 known vulnerabilities.go build ./...passes on both modules (toolchain auto-upgraded to go1.26.4).make generateproduces no drift —codegen-driftCI stays green.Release note
Summary by CodeRabbit