Skip to content

security(response): require exact response stream bytes - #200

Draft
seonghobae wants to merge 5 commits into
mainfrom
security/exact-response-stream-chunks-main-5e299
Draft

security(response): require exact response stream bytes#200
seonghobae wants to merge 5 commits into
mainfrom
security/exact-response-stream-chunks-main-5e299

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Purpose

Repair a finite-response accounting defect at the private HTTPX/HTTPCore stream boundary. Protected main historically counted len(chunk) before requiring the response chunk to be exact built-in bytes. A bytes subclass could override __len__ and under-report its real payload, allowing the bounded stream wrapper to yield more than max_response_bytes.

This is a dependency-shape/resource-integrity boundary, not a claim that the pinned HTTPCore version emits hostile chunks or that EgressWeave sandboxes arbitrary in-process Python.

Test-first lineage and current implementation

  • live protected base: 7faf7a3b8a47980113982914000e724ab6a6cda5;
  • exact current head: 0cb76cf32c59263f7cd1c9f01e2f01aa2689f4ed;
  • immutable RED lineage began with tests using a bytes subclass whose __len__ falsely returned zero while the underlying payload exceeded the policy budget;
  • current production fix requires type(chunk) is bytes before length accounting in both synchronous and asynchronous response wrappers;
  • rejected non-exact chunks use the existing fail-closed cleanup path and a generic non-leaking denial;
  • exact-byte behavior, authority/DNS/TLS binding, redirect/proxy/Unix-socket isolation, response ceilings, and process-control exception semantics remain unchanged.

Focused/full CI, Python 3.10–3.14 (including 3.14), package build, exact coverage evidence, SAST, CodeQL, Trivy and OSV are green on this exact head. No formal reviews or unresolved review threads exist on the exact head.

Current non-passing acceptance evidence

Keep this PR Draft. Do not merge or treat aggregate wrapper success as acceptance yet:

  1. Security Scan run 31616059331 is wrapper-green, but its exact-head dependency-review job 94179036000 skipped the actual Dependency review action. Skipped required supply-chain evidence is non-passing. The root fix is separately governed in read-only central PR ContextualWisdomLab/.github#897; do not replace it with a weaker EgressWeave-local gate or churn this clean head.
  2. Exact-head Strix check 94179030638 concluded success only after warning Strix backend unavailable; no vulnerability report was produced. Under EgressWeave release/merge evidence semantics, that infrastructure-neutral result is not a passing semantic security review.

Acceptance criteria

  • Preserve immutable RED evidence for under-counting through a non-exact bytes chunk.
  • Require exact built-in bytes before response-byte accounting in sync and async wrappers.
  • Deterministically close rejected streams and emit only the generic denial boundary.
  • Preserve ordinary exact-byte streaming and all existing authority/DNS/TLS/proxy/request/response invariants.
  • Pass exact-head focused/full CI, Python 3.10–3.14, package, exact coverage and static/security scanners that actually executed.
  • Obtain a fresh exact-head Security Scan where the actual immutable-pinned Dependency review action executes and succeeds.
  • Obtain fresh exact-head Strix semantic evidence that produces a real report rather than infrastructure-unavailable neutral success.
  • Validate any current automated/human findings against this unchanged head and resolve only addressed threads.
  • Merge only if the unchanged exact head satisfies the live ruleset and every required gate.

@coderabbitai

coderabbitai Bot commented Aug 12, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8922e1da-3c09-441a-a13d-401112eac424

📥 Commits

Reviewing files that changed from the base of the PR and between 7faf7a3 and 0cb76cf.

📒 Files selected for processing (3)
  • CHANGELOG.md
  • src/egressweave/response_safety.py
  • tests/test_response_stream_exact_bytes.py

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

@coderabbitai

coderabbitai Bot commented Aug 12, 2026

Copy link
Copy Markdown
⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@seonghobae
seonghobae marked this pull request as ready for review August 12, 2026 23:15
@seonghobae
seonghobae marked this pull request as draft August 13, 2026 00:19

Copy link
Copy Markdown
Contributor Author

@coderabbitai review
@opencode-agent review
@cwl-noema-review review

Review exact current head 0cb76cf32c59263f7cd1c9f01e2f01aa2689f4ed only against live protected main 7faf7a3b8a47980113982914000e724ab6a6cda5. Validate that synchronous and asynchronous response wrappers require exact built-in bytes before length accounting, reject dependency-controlled subclasses through the existing generic non-leaking denial, deterministically close the rejected source, preserve exact-byte streaming within budget, and keep the bounded three-file scope. The prior wrapper-green Dependency Review and unavailable Strix evidence are not merge authority. Submit a real current-head source-review verdict; do not mutate or merge.

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Rate Limit Exceeded

@seonghobae have exceeded the limit for the number of chat messages per hour. Please wait 23 minutes and 8 seconds before sending another message.

@seonghobae seonghobae left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current-head source review for 0cb76cf32c59263f7cd1c9f01e2f01aa2689f4ed found no blocking defect in the response-stream exact-byte boundary. Both sync and async wrappers require exact built-in bytes before invoking polymorphic length behavior, route rejection through deterministic source cleanup and the stable generic denial, and retain ordinary exact-byte streaming within the finite response budget. This is author-side review evidence only, not independent approval. Keep Draft until fresh corrected Dependency Review and authoritative Strix evidence run on the unchanged head and an independent current-head review is present.

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