acceptguard

Overview ¶

Command acceptguard finds gopherstack handlers that accept a REQUEST member the real pinned aws-sdk-go-v2 Input type does not declare -- the mirror image of every wire bug this campaign has found so far, which were all on the response side (a member emitted under the wrong key, dropped, or invented). networkmanager's ListAttachments/ListPeerings EdgeLocation filter was the case that first surfaced this direction (gopherstack-6flj); see this package's doc comment continuation in scan.go and this tool's own test file for why that specific historical commit (5591e3014) turned out, on structural inspection, NOT to be an instance of this class after all -- an important calibration finding in its own right, not a tool bug.

GROUND TRUTH, not a naming guess, reusing cmd/enumcheck's and cmd/zeroguard's own per-service SDK module resolution (modresolve.go, copied verbatim) and go/ast struct parsing (sdkfields.go):

• A gopherstack top-level struct whose name ends in one of requestSuffixes (Input/Request/Params/Req) is a candidate "what this handler accepts" shape. Stripping the suffix and capitalizing the first rune proposes a real AWS operation name (createVpcAttachmentReq -> CreateVpcAttachment).
• That candidate is verified, not assumed: it only proceeds if the pinned SDK module actually declares api_op_<Op>.go with an <Op>Input struct (sdkfields.go's fieldsFor).
• Every one of the candidate struct's own top-level fields is compared, case/abbreviation-folded (zeroguard's matchSDKField precedent), against that real Input's field set. A field present there is fine and produces nothing.
• A field ABSENT from the target op's real Input is only reported once REACHABILITY is confirmed structurally: some function in the package binds a local identifier to the struct's type (a parameter or `var` declaration) and reads `<that identifier>.<field>` somewhere in its body. A decoded-but-never-read field is this repo's documented non-bug (an emulator-internal hook unreachable from the real wire path) and is silently skipped, not reported at either confidence level.
• CONFIDENT (kindInvented): the field's name (folded) matches NO member of ANY real Input struct anywhere in the resolved SDK module -- not just absent from this op, absent from the entire service's real surface. Invented wholesale.
• NEEDS REVIEW (kindSibling): the field's name IS a real member, just of a different operation's Input in the same module -- the repo's other documented non-bug (a field that lives on a sibling or Create/Update- paired Input) made concrete and worth a human's look rather than silently dropped, since the field could genuinely be wired to the wrong op.

PROTOCOL SCOPE, disclosed rather than silently under-covered: this signal only sees a REQUEST shape gopherstack represents as a genuine Go struct with named fields -- every JSON-family service this repo has (a decoded body, or an apigatewayv2-style hand-populated params struct) qualifies. Query and ec2-query services pull request members out of url.Values by literal key (`vals.Get("SomeParam")`) with no struct to enumerate fields from at all, and REST-XML services with flattened/indexed member names (Filters.Filter.1.Name) would need a wire-key grammar this tool does not implement -- both protocol families see zero candidates and zero findings, not a false "clean" verdict for a different reason: there was never a struct here for this tool to examine in the first place.

SCOPE, disclosed rather than silently under-covered: only files directly in services/<dir> are scanned for candidate structs and their usage (no recursion into subpackages, no _test.go files); only a struct's own TOP-LEVEL fields are checked -- a mismatch nested inside a pointer-to- struct member (e.g. Options *vpcOptionsWire) is a different shape and out of this tool's signal entirely, matching zeroguard's own disclosed nested- struct exclusion.

Usage:

go run ./cmd/acceptguard                   # report to stdout
go run ./cmd/acceptguard -json out.json     # also write full finding list as JSON

Exit codes: 0 no confident findings (needs-review hits may still print), 1 a run error, 2 at least one confident finding.