build(deps): bump google.golang.org/grpc from 1.82.1 to 1.83.2 in /server

[dependabot]

Bumps google.golang.org/grpc from 1.82.1 to 1.83.2.

Release notes

Sourced from google.golang.org/grpc's releases.

Release 1.83.2

Security

• server: Reject requests missing both :authority and Host headers with HTTP 400 and status Internal. (grpc/grpc-go#9365)
  • Special Thanks: @​winklemad

Release 1.83.1

Security

• xds/rbac: Fix a bug where nested Principal or Permission rules with :scheme or grpc- prefixed header matchers were not rejected, which could cause DENY rules to fail open. (#9258)
  • Special Thanks: @​nvxbug
• xds/rbac: Fix a bug where the host header matcher was not being replaced with :authority in nested Principal or Permission rules. (#9258)
  • Special Thanks: @​nvxbug
• xds/rbac: Fix a bug where a header matcher whose name was not lowercase, such as X-Role, matched no header, which could cause DENY rules to fail open. (#9332)
  • Special Thanks: @​alimony
• xds/rbac: Fix a bug where a :scheme or grpc- prefixed header matcher was accepted when its name was not lowercase. (#9332)
  • Special Thanks: @​alimony
• xds/rbac: Fix a bug where a Host header matcher was not replaced with :authority. (#9332)
  • Special Thanks: @​alimony

Performance

• transport: Restrict memory overhead of buffering small data frames. (#9331)

Release 1.83.0

Security

• server: Stop reading from connections when flooded by HTTP/2 frames to mitigate resource exhaustion. The default value for this limit is 100 frames, excluding DATA and HEADERS, and may be changed by setting environment variable GRPC_GO_EXPERIMENTAL_CONTROL_BUFFER_THROTTLE_LIMIT.
• xds/rbac: Support Metadata and RequestedServerName permissions matcher fields. If present in a DENY rule, previously these would be ignored and fail-open.
• xds/rbac: Fix panic when parsing unsupported fields in NotRule/NotId permissions.
• xds/rbac: Support the deprecated source_ip principal identifier by treating it as equivalent to direct_remote_ip.
• xds: Fix panic when parsing route header matchers configured with empty exact_match, prefix_match, or suffix_match strings. (#9223)

New Features

• xds/googlec2p: Enable DirectPath over Interconnect support for on-premises clients via the force-xds target URI query parameter. (#9133)
• xds: Enable xDS configuration to control which fields get propagated from ORCA backend metric reports to LRS load reports. (#9145)
• authz: Add OnPolicyUpdate callback to FileWatcherOptions to notify when an authz policy is loaded or updated. (#9142)
  • Special Thanks: @​hnefatl
• xds: Add support for the GCP Authentication HTTP Filter, which automatically fetches and attaches GCP Service Account Identity JWT tokens to outgoing RPCs.
  • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_GCP_AUTHENTICATION_FILTER=true. (#9119)
• xds: Add support for xDS-based HTTP CONNECT proxies.
  • This feature can be enabled by setting environment variable GRPC_EXPERIMENTAL_XDS_HTTP_CONNECT=true. (#9151)
• xds: Add support for contains_match in route header matchers. (#9223)

Bug Fixes

• credentials/alts: Fix panic when processing malformed frames by validating that the message frame length exceeds the message type field size. (#9197)
• grpc: Fix compilation on Plan 9 targets (GOOS=plan9), broken since v1.81.0. (#9255)
  • Special Thanks: @​Yusufihsangorgel

... (truncated)

Commits

• 030ee8b Update version to 1.83.2 (#9375)
• 8668b69 cherry-pick #9365 to v1.83.x (#9366)
• a3e952d cherry-pick #9346 to v1.83.x and update x/net dependency (#9369)
• 58f8fd9 Change version to 1.83.2-dev (#9337)
• 1550d9e Change version to 1.83.1 (#9336)
• ebba6f3 Cherry-pick #9258 and #9332 into v1.83.x (#9335)
• 8cfeca0 Cherry-pick #9331 to v1.83.x (#9333)
• dec6951 Change version to 1.83.1-dev (#9229)
• 4c226da Change version to 1.83.0 (#9228)
• c198988 Cherrypick 9223 into v1.83.x (#9279)
• Additional commits viewable in compare view

[sun-970]

发现问题并修改的问题

[waterbro-8]

@dependabot rebase

[dependabot]

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry!

If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request @dependabot recreate.

[PeterGuy326]

Independent review: the diff is limited to google.golang.org/grpc and its go.sum/go.mod resolution. The server dependency tests and the full Go test suite passed locally; required CI is green. The upstream release notes include the xDS/RBAC fail-closed and HTTP/2 robustness fixes relevant to this service. Approving for squash auto-merge.

[waterbro-8]

Not a review. This comment carries no approval or request-changes, is not an acceptance, and authorizes nothing. I did not merge, close, unqueue, re-label, re-assign, or run "Update branch" on anything. Readings are live as of 2026-09-08T03:46Z and re-checked immediately before this comment was posted (04:08Z, visible in its own timestamp) and will age.

1. This is a security fix, not a routine bump

There is an open HIGH Dependabot alert on this repository for the exact package this PR moves — alert #74, still open when this comment was posted:

• GHSA-vp52-pcj8-j9qc / CVE-2026-84304 — "gRPC-Go: Heap Memory Exhaustion (OOM) via HTTP/2 DATA Frame Fragmentation"
• vulnerable range <= 1.83.0, first_patched_version = 1.83.1 — which is precisely this PR's target
• the corresponding line in the upstream v1.83.1 release notes: "transport: Restrict memory overhead of buffering small data frames. (#9331)"

For scale, in both directions: that same query returns five open alerts, so merging #158 does not clear the board — #71/#72/#73 (pypdf, medium) and #75 (postcss-selector-parser, low) stay open regardless. #158 is the only high one, and it is not even the only alert with a PR up: #156 (pypdf → 6.16.1) and #160 (postcss-selector-parser → 6.1.4) are sitting open too, all three from the same bot.

It reads like a minor-version jump for a patch-level advisory because there is no 1.82.x backport — the advisory lists only 1.83.1. So crossing the minor boundary is the only patched path from 1.82.1; the go.mod change is minimal-by-necessity, not careless.

2. Verification I actually ran (not a diff read)

Provenance first. Snapshot at 2026-09-08T03:46Z: compare/main...head gave merge base 7a194f1eba4167d54bd46cf84cdbe86e00532319 (then the main tip), status=ahead, ahead_by=3, behind_by=0, and a file set of exactly {server/go.mod, server/go.sum}. That matters here, because this Dependabot branch was refreshed against main twice by hand through GitHub's own UI — both merge commits carry committer.user = web-flow. Those two merges add no code changes.

I then took server/go.mod and server/go.sum from head 9d265c5b16e25fb1d6a091b9819c37b0fe6cc161 and applied them to a checkout sitting at the merge base, on Linux / Go 1.25.0:

• go build -mod=readonly ./... → rc=0
• go vet -mod=readonly ./... → rc=0
• go test ./internal/workerclient/... ./internal/indexer/... → both ok (those two packages plus generated internal/workerpb are the only consumers of gRPC here)
• control: the same build/vet on unmodified 7a194f1 also rc=0, so the green above is not my environment flattering the candidate

-mod=readonly passing across the full package set including tests is the useful part: it means go.mod needs no update and go.sum already has every hash the build list requires.

Transitive requirements check out without touching anything else — grpc 1.83.1 asks for golang.org/x/net >= 0.55.0, x/sys >= 0.45.0, x/text >= 0.37.0, x/crypto >= 0.51.0, and this module already pins 0.57.0 / 0.47.0 / 0.40.0 / 0.54.0. The otel 1.43.0 -> 1.44.0 and genproto/googleapis/rpc lines in go.sum are the new graph, not unrelated drift.

What I did not verify: go mod tidy could not run here (proxy.golang.org:443 is unreachable from this machine), so I am not claiming the files are tidy-canonical. I am only claiming the readonly-completeness result above.

3. Sizing the exposure honestly

Merging this is right, but it is not an incident for this repo, and I would rather say so than inflate it:

• production Go code here is a gRPC client only — server/internal/workerclient/client.go:112 (grpc.NewClient). The only grpc.NewServer calls in the tree are test fixtures at server/internal/indexer/managed_usage_outbox_integration_test.go:2038 and :2082; the serving side is the Python worker.
• so the advisory's scenario — an unauthenticated remote attacker opening streams against a grpc-go listener — does not describe anything this binary binds.
• residual exposure is the response path: client.go:28,114 dial over insecure.NewCredentials(), and client.go:11-12 states the assumption in writing ("worker is expected to be on the trusted LAN/cluster, not WAN"). Anyone positioned to answer or tamper with that plaintext endpoint is a peer this client trusts at the transport layer.
• one thing not to count as existing mitigation: grpc.MaxCallRecvMsgSize(64*1024*1024) at client.go:116. The advisory's whole point is that the memory inflation stays within flow-control limits; a message-size cap does not bound per-frame bookkeeping.

4. State has moved under this PR, and the green predates the new gates

As of 2026-09-08T03:46Z: main is now 2986fe38175f54d99f15dd38a498708c6ecd88cd (the squash of #167, the security baseline), and #158 reports mergeable_state=behind — not blocked, and not mergeable as-is.

The consequence is specific: #158's 15/15 green was produced by the workflow set that existed when this branch last touched main. commits/2986fe38…/check-runs now carries 19 check names against this head's 15. Missing from this head entirely:

• CodeQL (go), CodeQL (python), CodeQL (javascript-typescript)
• Dependency review
• OpenSSF Scorecard

i.e. the CVE-fix PR has not run the checks whose purpose is dependency and source hygiene. Those legs will only execute after the branch is refreshed.

5. What the gate is actually short, and what refreshing the branch costs

Live as of the moment this comment was posted:

• Exactly one approving review: @PeterGuy326 APPROVED on head 9d265c5b16e2 at 2026-09-06T03:13:30Z. It postdates the last commit on this head, so it is a live review, not a stale one.
• requested_reviewers = [@Bindy-lbb, @waterbro-8].
• auto_merge is already enabled — by @PeterGuy326, squash, commit title "squash merge PR build(deps): bump google.golang.org/grpc from 1.82.1 to 1.83.2 in /server #158 after independent review". Nobody needs to be asked to press merge; it is waiting on conditions.

So the missing thing is a second approving review, and on the current head the only requested reviewer who is not me is @Bindy-lbb.

The trap is that §4 and this interact. behind means this head has to be refreshed before it can merge, and a refresh dismisses the one live approval on it — observed directly on #140, where an APPROVED flipped to DISMISSED at push time. The branch update is therefore paid for in approvals, not in time.

Two PRs in this repo reached merged_at, so nobody has to guess what the passing shape looks like:

	#167 — merged 2026-09-08T02:58:17Z	#137 — merged 2026-09-04T08:43:06Z
final head	3b1b158ed7e2	ab8279a9c3a5
approvals on that head	2 (@Bindy-lbb 09-06T16:26:13Z, @waterbro-8 09-07T02:25:36Z)	2 (@waterbro-8 09-04T06:26:22Z, @Bindy-lbb 09-04T08:28:17Z)
push after the last approval	none	none
was an approver also the author of the head?	no	yes — this account, on the head it approved

I used to read #137 as proof that an operator's own approval counts. The date undercuts that: the protection config (require_code_owner=true, require_last_push_approval=true) was disclosed at 2026-09-04T15:43Z, roughly seven hours after #137 merged. So #137 is evidence about the earlier config, and I am not claiming what the current rule is. What I can offer is only the shape that is known to clear the gate today: two approvals on the head that ends up final, neither spent by a later push.

The rule itself is not readable from here (orgs/bytefolk/rulesets needs admin:org, which I don't have), so everything above is measured, not confirmed. Two questions that only someone who can read it can settle, and they change the shortest path:

1. Will the enabled auto-merge refresh the branch on its own, or does a human have to press "Update branch" — i.e. is @PeterGuy326's approval spendable or already spent?
2. Does a UI branch refresh (committer web-flow, §6) count as "the last pusher" the way a git push did on fix(ingest): serialize qoder checkpoint writers #140?

Held loosely, the arithmetic: the code-owner set is @PeterGuy326 @Bindy-lbb @waterbro-8, and §6 disqualifies me from being the useful second vote. So #158 wants @Bindy-lbb plus one other, after the branch stops moving. Ordering costs more than speed here.

6. Self-disclosure

Both Merge branch 'main' commits on this branch (5bdeb75bc9c9 at 2026-09-04T07:19:27Z, 9d265c5b16e2 at 2026-09-06T02:47:59Z) are attributed by GitHub's own API to this account — author.user.login = waterbro-8, committer.user = web-flow. They are branch refreshes I performed through the UI, not Dependabot's work. That is my second reason for posting a comment rather than a review: I am on the operator side of this head, so whatever §5's rule turns out to be, my approval is the one to be suspicious of. Treat §2 as verification evidence, not as a vote.

One more thing so it stops being news later: those commits carry a personal author email rather than this account's noreply address. It is not exposure created by this PR — the same address is already on main (4 of its last 100 commits, incl. 87d235b7cffe from #161), and #102's email rule is not consistently applied across this org's history anyway. It is a setting on my side to change going forward; rewriting published history is not on the table and I won't do it.

Not done, deliberately: no review submitted, no merge, no auto-merge change, no branch update, no label/assignee/milestone change, no closing of the Dependabot alert, and no message posted to any chat channel.

Dismissing my own approval of 2026-09-06. It is no longer correct: GHSA-2v4p-qf9q-27wj (published 2026-09-08, high) covers google.golang.org/grpc >= 1.83.0, < 1.83.2, so the 1.83.1 target this PR bumps to is itself vulnerable. The Dependency review gate (fail-on-severity: high, fail-on-scopes: runtime) correctly fails on this head. Patched version is 1.83.2.

[PeterGuy326]

Do not merge this PR. Dismissing my own approval of 2026-09-06 — it was correct when written and is wrong now.

What the Dependency review gate found

The failure on head 5343cab3 is not flake and not a stale duplicate run. It is a true positive:

server/go.mod » google.golang.org/grpc@1.83.1
  gRPC-Go xDS servers: Denial of Service (DoS) via crash due to
  missing `:authority` and `Host` headers (high severity)
  -> https://github.com/advisories/GHSA-2v4p-qf9q-27wj

The gate runs fail-on-severity: high with fail-on-scopes: runtime, and grpc is a runtime dependency of server/. So this check is doing exactly its job.

Why 1.83.1 is the wrong target

server/go.mod on main is at 1.82.1, which has three open alerts. Their patched versions, read from the advisory API:

Advisory	Severity	Vulnerable range	First patched
GHSA-vp52-pcj8-j9qc	high	<= 1.83.0	1.83.1
GHSA-qc2q-p7wx-3px3	medium	<= 1.83.0	1.83.1
GHSA-2v4p-qf9q-27wj	high	< 1.82.2 and >= 1.83.0, < 1.83.2	1.82.2 / 1.83.2

This PR lands 1.83.1, which closes the first two and is itself inside the third one's range. Net effect: one high alert traded for a different high alert, and the gate stays red.

GHSA-2v4p-qf9q-27wj was published 2026-09-08, two days after my approval, which is why the approval looks reasonable in isolation. It is not.

The only version that clears all three is 1.83.2 (released 2026-08-25).

Action

@dependabot recreate

Recreating against the current advisory set should target 1.83.2. If it does not, a manual build(deps): bump google.golang.org/grpc from 1.82.1 to 1.83.2 in /server is the change that is needed; main is carrying two high-severity advisories today, so this is worth not waiting on.

Leaving this PR open rather than closing it by hand so the recreate lands on the same thread.

[PeterGuy326]

Approving for squash auto-merge.

Why this approval replaces the one I dismissed

I approved this PR's predecessor at 1.83.1 and then dismissed that review (PUT /pulls/158/reviews/5123915933/dismissals) because it was wrong: 1.83.1 sat inside a high-severity advisory range that published after Dependabot opened the PR. I asked Dependabot to recreate it. This head is the result, and it targets 1.83.2.

The reason that history is worth restating rather than quietly re-approving: my dismissed review asserted that 1.83.1 carried specific upstream fixes. That assertion was true and irrelevant — a bump can carry the fixes it claims and still land inside an advisory. What follows is the check that actually matters.

Advisory verification, queried live just now

GET /repos/bytefolk/mem/dependabot/alerts?state=open returns exactly three open alerts, all on server/go.mod, all google.golang.org/grpc:

Alert	GHSA	Severity	Vulnerable range	First patched	Cleared by 1.83.2?
#74	GHSA-vp52-pcj8-j9qc	high	<= 1.83.0	1.83.1	yes — 1.83.2 > 1.83.0
#78	GHSA-2v4p-qf9q-27wj	high	< 1.82.2	1.82.2	yes — 1.83.2 ≥ 1.82.2
#79	GHSA-qc2q-p7wx-3px3	medium	<= 1.83.0	1.83.1	yes — 1.83.2 > 1.83.0

1.83.2 is the minimum version that clears all three simultaneously, and it is above every first_patched_version in the set. Choosing it over 1.83.1 is specifically what closes #78, whose range the earlier target fell inside.

Diff scope

Two files, nothing else:

• server/go.mod +5/-5 — the only dependency line moved is google.golang.org/grpc v1.82.1 → v1.83.2
• server/go.sum +20/-20 — hash lines for grpc and its transitive set

No source file, no workflow, no test, no lockfile outside the Go module graph.

CI

20/20 checks green on head efb231b8f85d48c5ba42fec5eb79933949e502d8, zero non-success. That includes all three required CodeQL contexts — CodeQL (go), CodeQL (python), CodeQL (javascript-typescript) — plus Go and PostgreSQL integration.

Worth stating why that is not automatic: this is a same-repo branch (bytefolk/mem, fork: false). bytefolk-security.yml:36 guards the CodeQL job with github.event.pull_request.head.repo.full_name == github.repository, so a fork head would skip it and the required contexts would never report. I have left a note on the three open fork PRs in this repository (#125, #172, #181) that are permanently blocked by exactly that. This PR is not one of them.

What I am not claiming

I have not built the server against 1.83.2 locally, and I have not exercised any gRPC code path by hand. The evidence is: the version arithmetic above, the diff being confined to the module graph, and CI's own Go and PostgreSQL-integration legs passing on this head. For a Dependabot patch-level bump inside a range whose advisories I have read, that is the proportionate bar — but it is CI's green, not a manual run, and I would rather name that than let it pass as something stronger.

require_last_push_approval is on for this repository, so this approval counts only because Dependabot is the last pusher on this head. If a maintainer pushes to the branch, my approval stops being sufficient and a fresh one is needed.