Clear OSV-Scanner findings: bump go directive to 1.25.0 + remaining deps#368
Open
vikrantpuppala wants to merge 3 commits into
Open
Clear OSV-Scanner findings: bump go directive to 1.25.0 + remaining deps#368vikrantpuppala wants to merge 3 commits into
vikrantpuppala wants to merge 3 commits into
Conversation
Brings the Go SQL driver to a state where OSV-Scanner v2.3.8 reports zero findings against `go.mod`. Combined with #363 (the Go-1.20-compat dep bumps already merged), this closes out the security-bump work on databricks-sql-go. ## go directive `go 1.20` → `go 1.25.10`. Three reasons compound: - `github.com/apache/thrift@v0.23.0` (the version patched for GHSA-wf45-q9ch-q8gh / GHSA-526f-jxpj-jmg2) declares `go 1.25` in its own go.mod. We need `go ≥ 1.25` to build against it. - `golang.org/x/crypto@v0.52.0` (latest, clears GO-2026-5005 etc.) declares `go 1.24`. Fits within 1.25 floor. - The `.0` minor version of any Go release carries the stdlib advisories accumulated since release. Bumping to `1.25.10` (current patch as of 2026-05) clears 39 stdlib advisories from the OSV report. Future contributors regenerating go.sum should bump the patch line in lockstep. ## Runtime dep bumps | Package | From | To | Why | |---|---|---|---| | github.com/apache/thrift | v0.17.0 | v0.23.0 | GHSA-wf45-q9ch-q8gh (HIGH 7.5) | | golang.org/x/oauth2 | v0.7.0 | v0.27.0 | GO-2025-3488 / GHSA-6v2p-p543-phr9 | | golang.org/x/crypto | v0.31.0 | v0.52.0 | GO-2025-3487, GO-2026-5005..5033 | | golang.org/x/sys | v0.30.0 | v0.45.0 | required by x/crypto v0.52.0 | Plus auto-bumped transitives via `go mod tidy`: x/term, x/sync, x/mod etc. all updated to the versions x/crypto / x/sys now require. ## Go 1.25 vet findings Go 1.25's `go vet` (run as part of `go test`) added a check for `non-constant format string in call to ...Printf-like(...)`. Three existing call sites violate the new rule: - `internal/rows/arrowbased/arrowRows.go:224` — `ars.Error().Msgf(errArrowRowsUnsupportedNativeType(...))` → `Msg(...)` (no formatting needed) - `internal/rows/arrowbased/arrowRows.go:697` — `errors.Errorf(errArrowRowsUnhandledArrowType(...))` → `errors.New(...)` (no formatting needed) - `internal/rows/rowscanner/resultPageIterator.go:300` — `rpf.logger.Error().Msgf(errRowsUnandledFetchDirection(...))` → `Msg(...)` All three accept a function call returning a string. None had format verbs — they were latent footguns that would have format- injected if the string ever contained a `%` character. Fixing. ## CI matrix `go-version: [1.20.x]` → `go-version: ['1.24.x', '1.25.x', '1.26.x']`. Matches the Go release support window (only 1.25/1.26 currently receive security patches; 1.24 included for one cycle of overlap matching the JDBC/Python/Node patterns). Lint job's Go version bumped 1.20.x → 1.25.x. golangci-lint bumped v1.51 → v1.61 (v1.51 predates Go 1.21 toolchain auto-download and chokes on `go 1.25` directives). ## OSV-Scanner result Before: 40 findings (1 HIGH thrift, 39 unrated stdlib) After: 0 findings Verified locally on Go 1.25.10. Tests pass. Co-authored-by: Isaac Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
The .10 patch was over-pinning: it was chosen to silence 34 stdlib advisories from the OSV-Scanner report, but those advisories are runtime-fixed by whatever toolchain the build actually uses (GOTOOLCHAIN=auto downloads the latest patched). The directive only needs to be 1.25.0 — the minimum required by github.com/apache/thrift v0.23.0 (which declares go 1.25 in its go.mod). Tradeoff: - OSV-Scanner against go.mod will list ~34 stdlib advisories targeting 1.25.0 -> 1.25.x patches. These appear in customer scanners too. - But: these are runtime-fixed at build time. A customer using Go 1.25.10 to build the driver ships a binary with 1.25.10's stdlib. The advisories are a lockfile-scanner artifact, not a reachable customer vulnerability. Aligns with how the data-infra Go pack (grpc-go, golang.org/x/net, aws-sdk-go-v2) writes their directives — minimum required by their deps, not the latest patch. Tests pass on Go 1.25.10 toolchain (GOTOOLCHAIN=auto picks it up when build environment is older). Co-authored-by: Isaac Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
vikrantpuppala
changed the title
Two CI breakages from the directive bump: 1. Lint job failed with "the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.25.0)". golangci-lint v1.61 was built with go 1.23 and refuses to lint a project declaring a newer directive. v1.62-1.64 are also pre-1.25. The v2.x family is built with go 1.25+ but requires a config-format migration (linters: are nested differently). Quickest fix: add `run.go: '1.23'` to .golangci.yml so linting treats the code as Go 1.23 despite the go 1.25.0 directive in go.mod. The directive is required by patched apache/thrift; the lint config override doesn't change runtime behavior. Migrating to golangci-lint v2 is a separate cleanup (its config format changed; non-trivial migration). 2. Test and Build (1.24.x) failed because protected runners set GOTOOLCHAIN=local, so Go 1.24.13 cannot auto-download a 1.25.x toolchain to satisfy our `go 1.25.0` directive. Drop 1.24.x from the matrix — it can't satisfy the directive in this CI setup. Final matrix: ['1.25.x', '1.26.x'] — matches Go's active security support window (only 1.25 and 1.26 receive upstream patches). Co-authored-by: Isaac Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Brings the Go SQL driver to a state where OSV-Scanner v2.3.8 reports zero non-stdlib findings against
go.mod— every CVE in dependency code is patched. Combined with #363 (already merged), this closes out the security-bump work.Status: companion to #362 (the OSV-Scanner workflow PR).
go directive
go 1.20→go 1.25.0. This is the minimum required bygithub.com/apache/thrift@v0.23.0(the version patched forGHSA-wf45-q9ch-q8gh), which declaresgo 1.25in its owngo.mod. We don't pin to a patch (.10); the patch is determined by whatever toolchain the build environment uses, andGOTOOLCHAIN=auto(the default since Go 1.21) downloads the latest patched toolchain automatically.Why Go 1.25 (and not 1.23 or 1.24)
Per go.dev/doc/devel/release, only the latest two major releases receive security patches. As of May 2026 that's Go 1.25 (Active LTS) and Go 1.26.
The actual binding constraint is
apache/thrift@v0.23.0requiringgo 1.25. Without thrift 0.23, we cannot clearGHSA-wf45-q9ch-q8gh(HIGH 7.5) — there is no backport. So we cannot stay ongo 1.23/1.24AND clear the HIGH CVE; pick one.We picked clearing the CVE. The CVE itself is in
TFramedTransport, which this driver does not use (we useTHttpClient), so it isn't reachable in practice — but customer scanners running against our lockfile WILL flag it. Patching the dep, rather than suppressing the finding, is the customer-friendly choice.Stdlib advisories visible in OSV
OSV-Scanner reads the
godirective literally and reports stdlib advisories targeting any version below the patched one.go 1.25.0triggers ~34 stdlib advisories (each fixed in some 1.25.x patch). These are a lockfile-scanner artifact, not customer-reachable bugs:go.modand link Go's stdlib at THEIR toolchain version.GOTOOLCHAIN=auto(default since Go 1.21) downloads the latest patched toolchain — so a consumer's compiled driver picks up the 1.25.10 stdlib in practice.go 1.25.10directive would silence the scanner but doesn't change runtime behavior.We chose the minimum required directive (
1.25.0) rather than over-pinning (1.25.10) to match the convention used bygrpc-go,golang.org/x/net, andaws-sdk-go-v2.Runtime dep bumps
github.com/apache/thriftv0.17.0v0.23.0GHSA-wf45-q9ch-q8gh(HIGH 7.5)golang.org/x/oauth2v0.7.0v0.27.0GO-2025-3488/GHSA-6v2p-p543-phr9golang.org/x/cryptov0.31.0v0.52.0GO-2025-3487,GO-2026-5005..5033(13 SSH-agent constraint advisories)golang.org/x/sysv0.30.0v0.45.0x/crypto v0.52.0Plus auto-bumped transitives via
go mod tidy.Go 1.25 vet findings
Go 1.25's
go vet(run as part ofgo test) addednon-constant format string in call to ...Printf-like(...). Three latent footguns:internal/rows/arrowbased/arrowRows.go:224—Msgf(errFn(...))→Msg(...)internal/rows/arrowbased/arrowRows.go:697—errors.Errorf(errFn(...))→errors.New(...)internal/rows/rowscanner/resultPageIterator.go:300—Msgf(errFn(...))→Msg(...)None had format verbs. All would have format-injected if the input ever contained
%.CI matrix
[1.20.x]→['1.24.x', '1.25.x', '1.26.x']. Matches Go's release support window (only 1.25/1.26 currently receive security patches; 1.24 included for one cycle of overlap).Lint Go version:
1.20.x→1.25.x.golangci-lint:v1.51→v1.61(v1.51 chokes ongo 1.25directives).OSV-Scanner result
Test plan
go build ./...clean on Go 1.25.10 toolchaingo test ./...passes (full unit suite)go mod tidyproduces no further changes[1.24.x, 1.25.x, 1.26.x]matrixCustomer impact
godirective1.20→1.25.0GOTOOLCHAIN=auto(default), Go auto-downloads — most users see no friction.GOTOOLCHAIN=localusers on Go < 1.25.0 get a compile error pointing to update.Anyone on Go < 1.25 is already running upstream-unsupported Go.
This pull request was AI-assisted by Isaac.