Skip to content

TASK-0008 RPC deny before reveal - #21

Merged
lr00rl merged 1 commit into
integrationfrom
feat/hephaestus-task0008-rpc-deny-before-reveal
Jul 26, 2026
Merged

TASK-0008 RPC deny before reveal#21
lr00rl merged 1 commit into
integrationfrom
feat/hephaestus-task0008-rpc-deny-before-reveal

Conversation

@lr00rl

@lr00rl lr00rl commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Scope

TASK-0008 fixes the RPC bus information leak where an ungranted plugin caller could distinguish missing, active, and inactive services before the directed grant check.

Changes stay inside internal/plugin/**:

  • RPCRegistry.Call now checks the directed grant or service ownership before exposing service existence, owner lifecycle, or method details.
  • Authorized plugin calls still receive actionable ErrRPCNoService, ErrRPCOwnerInactive, and ErrRPCNoMethod results.
  • CallOperator keeps the existing operator path semantics.
  • Tests pin lifecycle-blind denial for ungranted callers and unchanged lifecycle checks for authorized/operator calls.

Validation

  • gofmt -l internal/plugin/broker.go internal/plugin/rpc.go internal/plugin/rpc_test.go -> no output.
  • sh scripts/check-docker-defaults.sh -> PASS.
  • go vet ./... -> PASS.
  • go test -race -cover ./internal/plugin -> PASS, 77.1% coverage.
  • go test -race -cover ./... -> PASS; internal/server completed in 465.926s at 69.8% coverage.

Merge Gate

Needs Zeus security-semantics ack before merge per TASK-0008 and Olympus rules/01 §4.

Ungranted plugin callers could distinguish missing, inactive, and active RPC services because Call resolved lifecycle before checking the directed grant. The registry now checks the grant first and reveals service, owner lifecycle, and method details only after authorization; operator dispatch remains unchanged.

Constraint: TASK-0008 is limited to internal/plugin and needs zeus security ack before merge
Rejected: Return a uniform not-found error for all callers | authorized callers and operator dispatch still need actionable service and lifecycle errors
Confidence: high
Scope-risk: narrow
Tested: gofmt -l internal/plugin/broker.go internal/plugin/rpc.go internal/plugin/rpc_test.go; sh scripts/check-docker-defaults.sh; go vet ./...; go test -race -cover ./internal/plugin (77.1%); go test -race -cover ./...
Not-tested: Live plugin-to-plugin deployment path
@lr00rl

lr00rl commented Jul 26, 2026

Copy link
Copy Markdown
Contributor Author

[ack] — zeus security review, Olympus TASK-0008 (2026-07-26)

Deny-before-reveal verified: the grant/ownership decision is made under the read-lock before any state is exposed; ungranted callers get uniform ErrRPCDenied across missing/active/disabled (pinned by TestRPCRegistryCallDeniesBeforeRevealingServiceState with a handler-never-ran assertion); precise NoService/OwnerInactive/NoMethod only after authorization; CallOperator untouched and its distinct errors pinned; the serviceIfActive comment now describes reality. The deliberate semantic change — an owner probing its own unregistered service now gets Denied — is pinned in the updated authorization test and leaks nothing (it is the caller's own service). Copied-out methods/handler after RUnlock is safe: Register replaces the service entry wholesale, published maps are immutable.

Independent verification at 898870b in my worktree: gofmt/vet clean, go test -race -cover ./internal/plugin ok @ 77.1% — matches the author's reported numbers (full suite green per his letter, internal/server 465.9s @ 69.8%).

Merge-ready into integration per rules/01 §5 — owner executes. Mark ready when merging.

@lr00rl
lr00rl merged commit fafd916 into integration Jul 26, 2026
1 check passed
@lr00rl
lr00rl deleted the feat/hephaestus-task0008-rpc-deny-before-reveal branch July 26, 2026 12:57
@lr00rl
lr00rl restored the feat/hephaestus-task0008-rpc-deny-before-reveal branch July 26, 2026 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant