Skip to content

fix(people): bind confirmed-hire ASGI body-frame authority before parsing #325

Open

Description

@seonghobae

Canonical owner: PR #55 confirmed-hire transport boundary.

Fresh audit after #324 found the remaining confirmed-hire request-body boundary still performs executable operations on unproven ASGI frame objects:

  • _read_json_object(...) invokes message.get(...) without proving an exact built-in dict frame;
  • it compares message["type"] without proving exact built-in str;
  • it accepts bytes/bytearray subclasses for body and then calls len(...) / extends the aggregate buffer.

The request body is already byte/frame/depth bounded, but those limits only matter after the transport frame and scalar representation are trusted. A custom/hostile ASGI adapter can therefore execute subtype behavior before the boundary's own validation.

Required repair: test-first hostile frame/type/body regressions; require exact built-in frame/scalar authority before get, comparison, length, or buffer extension; preserve normal ASGI dict + bytes frames, 400/413 semantics, bounded frame count/size/nesting, and zero mutation-port execution on rejection. Keep open until exact-head protected acceptance/integration.

Activity

  1. seonghobae commented on Sep 14, 2026

    @seonghobae
    ContributorAuthor

    #325 is repaired on canonical owner PR #55.

    • test-first: 9a362b4d77b71b16b906b665b14f2633135bd97b
    • causal repair / current exact owner head: bd1390a79e04ea9f44179ab71d98acd20b5793bb

    The transport now proves an exact built-in ASGI body-frame dict before .get, an exact built-in message-type str before comparison, and exact built-in body bytes before length accounting or buffer extension. Regression coverage includes hostile dict/string/bytes subclasses, explicit bytearray rejection, and an exact built-in happy path. Existing frame-count/body-size/nesting limits are preserved.

    Exact-head Security 34832584337, SAST 34832584132, Foundation 34832584097, and CodeQL 34832584082 are queued. No hosted RED/GREEN or independent approval is claimed. Employment descendants were ordinary-forward restacked without force to #149 14901b478c38718838d406004146d1a4df28454e → #155 a41c5d943b44a7d5724c18491652529c841980c8 → #156 0d133eacc04e8bd413aeccf32046cf9140b0c517.

    Keep #325 open until exact-head protected acceptance and normal integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions