Version bumps for security (including go 1.25.9)#2434
Conversation
PR SummaryMedium Risk Overview Reviewed by Cursor Bugbot for commit ca916a7. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
packages/nomad-nodepool-apm/Dockerfile (line 2) — This Dockerfile was not updated as part of this security version bump. It uses a floating golang:1.25 tag rather than the pinned golang:1.25.9 used in all other package Dockerfiles — this defeats the purpose of explicitly pinning to a patched version. It should follow the ARG GOLANG_VERSION=1.25.9 pattern used across the rest of the repo.
| github.com/redis/go-redis/extra/redisotel/v9 v9.17.3 // indirect | ||
| github.com/rs/zerolog v1.34.0 // indirect |
There was a problem hiding this comment.
🔴 The security bump of github.com/redis/go-redis/v9 to v9.18.0 was not applied to the companion sub-modules github.com/redis/go-redis/extra/rediscmd/v9 and github.com/redis/go-redis/extra/redisotel/v9, which remain at v9.17.3 across all affected packages. This is a security gap: the PR's stated goal was a security update for Redis, but the extra sub-modules—including redisotel/v9 which is a direct production dependency in packages/shared for OpenTelemetry tracing—did not receive the same fix.
Extended reasoning...
What the bug is and how it manifests
The go-redis project uses a monorepo where the main module (github.com/redis/go-redis/v9) and its extra sub-modules (extra/rediscmd/v9, extra/redisotel/v9) are tagged in lockstep under the same Git tag (e.g., v9.18.0). This PR updates the main module from v9.17.3 to v9.18.0 for security reasons, but the two extra sub-modules remain at v9.17.3 in every affected go.mod file. This means the security fix in v9.18.0 is only partially applied.
The specific code path that triggers it
In packages/orchestrator/go.mod, lines 280-281 appear as unchanged context in the diff:
github.com/redis/go-redis/extra/rediscmd/v9 v9.17.3 // indirect
github.com/redis/go-redis/extra/redisotel/v9 v9.17.3 // indirect
while the same file shows:
-github.com/redis/go-redis/v9 v9.17.3
+github.com/redis/go-redis/v9 v9.18.0
The same pattern repeats in packages/shared/go.mod, packages/api/go.mod, packages/client-proxy/go.mod, and packages/dashboard-api/go.mod. The go.sum files for these packages contain no v9.18.0 hash entries for the extra sub-modules, confirming they were never fetched or updated.
Why existing code does not prevent it
Go's Minimum Version Selection (MVS) does not automatically co-upgrade sub-modules in the same monorepo. Each sub-module path is treated as an independent module. A developer running go get github.com/redis/go-redis/v9@v9.18.0 only updates that one module path; the extra sub-modules must be updated separately with explicit go get calls for each sub-module path.
Impact
The most significant concern is in packages/shared, where redisotel/v9 is a direct dependency (no // indirect marker) used for OpenTelemetry Redis tracing in production. If the v9.18.0 security fix addresses a vulnerability in shared code that the extra modules link against or call into, redisotel will still exercise the older, unpatched code path. Additionally, mismatched versions within the same monorepo can cause subtle behavioral inconsistencies between the main client and its instrumentation wrappers.
How to fix it
Run the following in each affected package directory:
go get github.com/redis/go-redis/extra/rediscmd/v9@v9.18.0
go get github.com/redis/go-redis/extra/redisotel/v9@v9.18.0
go mod tidy
v9.18.0 is confirmed to exist for both sub-modules on the Go module proxy.
Step-by-step proof
- PR diff for
packages/orchestrator/go.modshows+github.com/redis/go-redis/v9 v9.18.0(bumped) but lines forrediscmd/v9andredisotel/v9remain atv9.17.3(unchanged context, no+lines). - Same observation repeats in
packages/shared/go.mod— whereredisotel/v9is a direct dep. - The
go.sumfiles contain hashes only for v9.17.3 of the extra sub-modules, not v9.18.0, confirming the modules were never updated. - The go-redis project tags all modules together (main + extras) under the same version tag, so v9.18.0 exists for all sub-modules, yet they were left behind.
| module github.com/e2b-dev/infra/packages/shared | ||
|
|
||
| go 1.25.4 | ||
| go 1.25.9 |
There was a problem hiding this comment.
🔴 The packages/shared/go.mod file was bumped to go 1.25.7 instead of the target go 1.25.9. Every other package in this PR (api, auth, clickhouse, client-proxy, dashboard-api, db, docker-reverse-proxy, envd, local-dev, nomad-nodepool-apm, orchestrator) and the go.work file were correctly updated to 1.25.9. The shared module should be changed from go 1.25.7 to go 1.25.9 to get the full security benefit and maintain workspace consistency.
Extended reasoning...
What the bug is
The PR is titled "Version bumps for security (including go 1.25.9)" and its explicit goal is to update all Go modules to version 1.25.9 for security reasons. However, packages/shared/go.mod line 3 was set to go 1.25.7 instead of go 1.25.9. This is an inconsistency introduced by this PR — the file was changed from 1.25.4 to 1.25.7 (an intermediate version), not to the target 1.25.9.
The specific code path
In packages/shared/go.mod, line 3 reads:
go 1.25.7
while every other go.mod in the repository was updated to:
go 1.25.9
Why existing code does not prevent it
Go workspaces do not enforce that all member modules declare the same minimum Go version — each module can have its own. The toolchain will use the highest version required by any active module, but the minimum version specified in each module's go.mod is not automatically validated for consistency across a workspace.
Impact
The shared package is imported by essentially every other service in this monorepo (api, auth, clickhouse, client-proxy, dashboard-api, db, docker-reverse-proxy, envd, local-dev, nomad-nodepool-apm, orchestrator). Because this module is pinned at 1.25.7, it won't receive any compiler-level fixes or language-spec changes introduced between 1.25.7 and 1.25.9, defeating the stated security purpose for this specific module.
Step-by-step proof
- The PR title states the goal: bump all Go versions to
1.25.9for security. go.workis changed fromgo 1.25.4→go 1.25.9✓packages/api/go.modis changed fromgo 1.25.4→go 1.25.9✓packages/auth/go.modis changed fromgo 1.25.4→go 1.25.9✓- (Same for clickhouse, client-proxy, dashboard-api, db, docker-reverse-proxy, envd, local-dev, nomad-nodepool-apm, orchestrator — all →
go 1.25.9) ✓ packages/shared/go.modis changed fromgo 1.25.4→go 1.25.7✗ — should bego 1.25.9
Fix
Change line 3 of packages/shared/go.mod from go 1.25.7 to go 1.25.9.
No description provided.