deps: bump golang.org/x/crypto to v0.33.0 (fix CVE-2024-45337)

[talmacschen-arch]

What

Bump golang.org/x/crypto from v0.21.0 to v0.33.0.

Why

Fixes CVE-2024-45337
(GHSA-v778-237x-gjrc) — SSH PublicKeyCallback authorization bypass in
golang.org/x/crypto/ssh. First fixed in x/crypto v0.31.0.

Reachability

cbcopy does not import golang.org/x/crypto/ssh directly or
transitively:

$ go mod why golang.org/x/crypto/ssh
# golang.org/x/crypto/ssh
(main module does not need package golang.org/x/crypto/ssh)

The only sub-package actually pulled in is golang.org/x/crypto/pbkdf2,
via pgconn for PostgreSQL SCRAM-SHA-256 auth. That sub-package is
unaffected by the CVE.

The bump is therefore a module-level CVE clearance for SCA tooling
(Dependency-Track and similar), not a fix for an actually exploitable
path in cbcopy.

Why v0.33.0 specifically (not v0.31.0, not v0.51.0)

Version	x/crypto's go.mod go directive	Compatible with cbcopy's go 1.21
v0.31.0 (Dependabot's pick in #11)	go 1.20	yes
v0.33.0 (this PR)	go 1.20	yes
v0.34.0+	go 1.23.0	no — would force cbcopy's go directive up to 1.23

v0.33.0 is the highest x/crypto release that does not force
cbcopy's go directive past 1.21. It picks up additional fixes
shipped between v0.31 and v0.33 without dragging downstream builders
into a Go toolchain upgrade. Going to v0.34+ raises the project's
minimum Go to 1.23 and is out of scope for this PR.

Diff

• go.mod: one line bumped for x/crypto; go directive unchanged
  (still go 1.21); no toolchain directive introduced. Sibling
  golang.org/x/{sys,net,text,tools} refreshed to their minimum
  versions required by v0.33.0; go-cmp bumped to v0.6.0 (test util,
  pulled by x/tools).
• go.sum: corresponding refreshes only.
• No business-code dependency changes (pgx, pgconn, go-sqlmock
  untouched).

Verification

Static / build:

• grep '^go ' go.mod → still go 1.21
• grep '^toolchain ' go.mod → no match
• go mod why golang.org/x/crypto/ssh → "main module does not need..."
• go build ./... clean
• make build produces both cbcopy and cbcopy_helper binaries
• go vet ./... — output identical to upstream/main baseline (one
  pre-existing testutils/functions.go:648 unreachable code warning,
  not introduced by this PR)
• go test -c compiles for ./copy/..., ./helper/...,
  ./internal/dbconn/...

Tests (4-host SynxDB4 cluster, A/B'd against upstream/main with the same env):

• Unit tests for runnable suites (internal/dbconn, meta/builtin,
  meta/builtin/toc, option, testutils, utils) — green
• Full ./integration suite — 365 passed / 82 failed; failure
  set identical to upstream/main, no regression from this PR
• Full ./end_to_end suite — 15 passed / 0 failed;

Relation to #11

Dependabot opened #11 in Feb 2025 proposing v0.31.0. That PR has been
idle for 30+ days and lost auto-rebase. This PR proposes the same fix
at a slightly higher patch level (v0.33.0) that is the ceiling under
the current go 1.21 directive. Once this merges, Dependabot will
recognise v0.33.0 >= v0.31.0 and auto-close #11. No need to close
#11 manually.

[talmacschen-arch]

Integration suite re-verification + per-failure root-cause analysis

To verify the "failure set identical to upstream/main" claim at spec-name granularity (not just aggregate counts), I re-ran ./integration on the 4-host SynxDB4 cluster, 4 times.

Run summary

Run	Branch	Cluster	Pass	Fail	Wall
1	this PR (d528285)	clean	370	77	16.8s
2	upstream/main (4fa9725)	dirty (post run-1)	365	82	17.0s
3	upstream/main	clean	367	80	16.1s
4	this PR	clean	367	80	16.9s

comm-diff of sorted [FAIL] spec names between run-3 (main, clean) and run-4 (PR, clean):

only-in-MAIN: 0 specs
only-in-PR  : 0 specs

The two fail sets are byte-identical at spec-name granularity. The 77/80/82 swing in raw counts is entirely on 3 tablespace specs (see bucket 4 below) that flake regardless of branch — they pass on the very first run after a fully-clean cluster and fail on subsequent runs even after manual DROP TABLESPACE + rm -rf cleanup.

Per-failure root cause (all 80 fails)

Each ginkgo [FAILED] block parsed and grouped by SQLSTATE / failure mode:

#	Bucket	Count	Root	PR #36 related
1	SECURITY LABEL FOR dummy ... — dummy_seclabel contrib not built into this SynxDB4 (22023)	28	cluster build	no
2	$libdir/gps3ext.so (6) + plperl.so (3) not installed (58P01)	9	cluster build	no
3	pg_ext_aux schema pollution — SynxDB4 PAX catalog objects (pg_pax_fastsequence, paxauxstats_in, arrow_avg_int_bytea, …) leak into GetAllUserTables / GetFunctions / Get[type]Types etc. and break Equal() assertions; fixtures expect vanilla GPDB6/PG12 baseline	~30	test fixtures (stale)	no
4	test_tablespace BeforeEach not idempotent — first failure leaves it created, cascades through 7 tablespace-bound specs (42710)	7	test code	no
5	PG14 catalog drift — pg_statistic.stakind enum extended (Kind2 8 vs 3) + bool parser tightened (array_in('{"2"}', 'bool') now rejects); affects GetAttributeStatistics, PrintStatisticsStatementsForTable, a couple of Get[type]Types	~6	test fixtures (stale)	no

Bottom line

• The "failure set identical to upstream/main" claim is verified at spec-name granularity, not just aggregate counts.
• All 80 failures are cluster-config gaps or stale upstream test fixtures. Zero trace to cbcopy production code; zero are introduced or worsened by this PR.
• Buckets 3 and 4 are real cbcopy test-suite debt and worth a separate issue, but they exist on main today and are independent of this PR.
• The crypto bump remains a clean module-level CVE clearance for SCA tooling, as described.

Environment: 4-host SynxDB4 4.5.0-rc.3 (1 coordinator + 1 standby + 16 primary segs + 16 mirrors), go 1.21.13.

[talmacschen-arch]

Follow-up notes

Three supplemental disclosures from a second-pass review, to spare future reviewers from re-asking.

1. SCRAM-SHA-256 / pbkdf2 path not specifically exercised

The only golang.org/x/crypto sub-package reachable from cbcopy is pbkdf2, via pgconn for PostgreSQL SCRAM-SHA-256 client auth. Neither ./integration nor ./end_to_end forces SCRAM (the test cluster uses trust/peer auth), so no test specifically exercises that path before/after this bump.

The gap is theoretical, not a real risk:

• CVE-2024-45337 is in x/crypto/ssh, which is not transitively imported (go mod why golang.org/x/crypto/ssh → "main module does not need package golang.org/x/crypto/ssh").
• x/crypto/pbkdf2 has no source changes between v0.31 and v0.33.

Flagging this for transparency; not asking for a targeted SCRAM test as a merge blocker.

2. golang.org/x/mod v0.12.0 removal from go.sum is go mod tidy output, not manual

The diff drops:

-golang.org/x/mod v0.12.0 h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc=
-golang.org/x/mod v0.12.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs=

The bumped golang.org/x/tools no longer transitively requires x/mod v0.12, so go mod tidy correctly drops it from the build-time closure. Running go mod tidy on this PR head produces zero diff against the committed go.mod / go.sum — the files are already in canonical post-tidy form.

3. Follow-up debt: re-bump x/crypto when the go directive is raised past 1.23

This PR caps at x/crypto v0.33.0 because v0.34.0+ requires go 1.23.0, out of scope here. As of today the latest x/crypto release is v0.51.0 — 18 patch levels ahead — and that gap will keep widening for as long as the go 1.21 constraint holds.

When a future PR raises cbcopy's go directive past 1.23 (for any reason), x/crypto should be re-bumped to current latest in the same change, so the project doesn't end up in a "go directive at 1.23 but crypto still at v0.33" half-state. Worth a one-liner reminder on any such PR's checklist, or a separate tracking issue.