chore(deps): clear govulncheck — Go 1.26.7, excelize v2.11.0 - #8
chore(deps): clear govulncheck — Go 1.26.7, excelize v2.11.0#8saifulferoz wants to merge 1 commit into
Conversation
govulncheck started failing on every PR without any code change: both advisories were published after main last ran CI on 2026-07-21. GO-2026-6088 (encoding/xml, recursion depth during decode) — reached through excelize's row and conditional-format readers. The workflow asked for "1.26" and the runner's toolchain cache served 1.26.5, which carries it. Pinned to the 1.26.7 patch in both the workflow and the Dockerfile so the fixed stdlib is what actually gets used. GO-2026-5960 (excelize v2.10.1) — fixed in v2.11.0, which is a breaking upgrade: Chart.Title and ChartAxis.Title changed from []RichTextRun to a ChartTitle struct whose Paragraph field holds the runs. Migrated the three call sites in compat/chart.go; the pin is presumably why this was not taken earlier. Verified with the pinned toolchain: "No vulnerabilities found" (was 2). Full Go suite green under -race, and the go-test Docker stage pulls golang:1.26.7 and passes. Adds core/titlecheck_test.go: the ChartTitle migration is the one change here that could silently produce a wrong file rather than a build error, so this asserts the chart and axis title text actually reaches the generated chart XML. Confirmed it bites by blanking the title assignment. No behaviour change intended beyond the dependency bump.
|
Superseded by #7, which now carries these commits directly.
The cherry-pick did surface one thing this PR could not: wave 5.4's chart tests assert Closing to avoid carrying the same commit in two open PRs. |
Why
govulncheckstarted failing on every PR without any code change — bothadvisories were published after main last ran CI on 2026-07-21. This is
independent of #7; it branches from
mainand touches no shim or Compat code.GO-2026-6088 —
encoding/xml, recursion depth during decodeReached through excelize's row and conditional-format readers
(
Rows.Columns,GetConditionalFormats, andsheetPartPaths's ownxml.Unmarshal).The workflow asked for
go-version: "1.26"and the runner's toolchain cacheserved 1.26.5, which carries the vulnerability. Pinned to the
1.26.7patch in both the workflow and the Dockerfile so the fixed stdlib is what
actually gets used.
GO-2026-5960 — excelize v2.10.1
Fixed in v2.11.0, which is a breaking upgrade:
Chart.TitleandChartAxis.Titlechanged from[]RichTextRunto aChartTitlestruct whoseParagraphfield holds the runs. Migrated the three call sites incompat/chart.go. The pin is presumably why this had not been taken already.Verification
With the pinned toolchain:
Was 2 before this change (1 stdlib, 1 excelize).
-raceon go1.26.7 + excelize v2.11.0go-testDocker stage pullsgolang:1.26.7and passesNew test
extension/core/titlecheck_test.go. TheChartTitlemigration is the onechange here that could silently produce a wrong file rather than a build
error — assigning the wrong field would compile fine and just drop the title.
The test asserts the chart title and both axis titles actually reach the
generated chart XML. Confirmed it bites by blanking the title assignment.
Scope
No behaviour change intended beyond the dependency bump. The transitive
golang.org/x/*andmscfbbumps come fromgo mod tidy.