Serve only public portable objects from gateways by default - #1183

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 0 remain after this review.

Walkthrough

The change adds audience-signature checks to request and test contexts. Portable gateway responses now apply public-addressing, object-ID, proof, and authorization checks. The documentation and tests describe these rules and their response behavior.

Changes

Portable gateway access

Document loader timeout test

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant Requester
  participant FederationImpl
  participant handlePortableObject
  Requester->>FederationImpl: Request portable actor or object
  FederationImpl->>handlePortableObject: Dispatch with actor or object kind
  handlePortableObject->>handlePortableObject: Check expanded ID, addressing, and proof
  handlePortableObject-->>FederationImpl: Return gateway response
  FederationImpl-->>Requester: Return response

Security Blast Radius

• inferred — The independently reachable disclosure scope is the portable objects that an application exposes through registered gateway dispatchers. Anonymous callers can request those objects, but the new default restricts non-public non-actor responses. A configured predicate can still authorize broader access; the examined changes do not establish increased infrastructure, credential, or cross-tenant authority.

Security Findings and Attack Paths

• inferred — The previous anonymous private-object retrieval path is narrowed: a matching non-public non-actor object without a predicate now exits through not-found before proof verification. This blocks that route to the payload and avoids exposing proof-verification success or failure for an otherwise hidden, successfully serialized object.

Trust Boundaries and Controls

• observed — Private audience checks resolve the owner only after the request-signature verification call yields a key. Missing keys and key-owner fetch failures become unauthenticated. Direct recipients are compared canonically; only the application callback can grant collection-membership access.
• observed — Configured predicates remain authoritative and run before serialization; the handler does not automatically enforce audience matching when one exists. Actor routes and runtime Actor instances are exempt from the default visibility gate. Runtime-versus-serialized actor type alignment remains unresolved, but no concrete bypass or worsening of the previous permissive exposure was established.

Resilience and Maintainability Implications

• inferred — The examined serving transition has request-local intermediate state and terminates without constructing a payload response when identity, visibility, authorization, or required proof checks reject it. Sharing the serialized document and context loader reduces authorization/verification drift across awaits. Application-owned mutable objects and predicate reads remain outside that guarantee.

Hardening Proposals

• proposed — For application integrations, authorize against the same stable object snapshot that the dispatcher serves, and keep collection-membership decisions scoped to that object's policy. Where custom serialization is supported, explicitly preserve alignment between runtime actor classification and the serialized root type.

❌ Failed checks (1 warning)

• X
• Mastodon
• Reddit
• LinkedIn

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.