fix: bound /parse request body before multipart parsing - #787
fix: bound /parse request body before multipart parsing#787seonghobae wants to merge 40 commits into
Conversation
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@claude Fresh test-isolation RED is now on exact head Minimal GREEN on a normal descendant:
Do not clear or replace the whole override mapping, and do not create a source-neutral retrigger. If the branch advances, read/adopt the intervening delta and continue non-force. |
Acknowledged. |
현재 상태
/parse의 multipart parser 이전 request-body admission, parser 이후 form-field validation, pypdf security floor, test isolation을 한 canonical lineage에서 유지합니다. intervening descendants의 유효 test/security delta는 채택하되 generated repository doctrine과 과장된 security claim은 normal descendant로 수리합니다.develop@e06b1f3fb10903569124af011da213951e6e2473ebd6c71ba17151228c23d32705687097290c0c89CHANGELOG.md, dependency doctoring,pyproject.toml,/parsesource, focused parse/request-body/test-isolation/security tests,uv.lock.jules/sentinel.md는 protected-base blob과 일치하므로 effective diff에서 제거된 상태를 유지합니다.RED → GREEN → repair lineage
Content-Length는 body read 0회로 413, 길이가 없거나 신뢰할 수 없는 stream은 실제 누적 receive bytes로 제한하는 pre-parser RED를/parsePOST 전용 ASGI admission으로 GREEN 처리했습니다. PDF payload 20 MiB와 multipart/form framing budget 1 MiB를 분리해 총 21 MiB admission을 유지합니다.language/mode의max_length=50은 parser 이후 FastAPI form-value contract입니다. 이것을 multipart parser 이전 memory budget이라고 주장하지 않습니다.tests/test_parse_endpoint_max_length.py에서 두 필드를 parameterize하고 HTTP 422와 FastAPI/Pydantic의string_too_longlocation을 직접 고정합니다. 이 공개 validation shape를 존재하지 않는 sanitized response라고 표현하지 않습니다._runtime_settingsoverride만 복원하며 다른 fixture의app.dependency_overrides를 지우지 않습니다. 기존 destructive-clear 회귀도 별도 test-isolation contract로 유지합니다.pypdf>=6.16.2,<7.0와 lock 6.16.2를 유지합니다. 2026-09-05 재검증한 upstream advisory 기준으로CVE-2026-84309는 6.16.0,CVE-2026-84310/CVE-2026-84311은 6.16.1에서 각각 patched이며, PyPI의 현재 latest 6.16.2는 이 floor보다 최신입니다.docs/doctoring/dependency-security-baseline.md에 CVE↔GHSA↔patched-version↔PyPI provenance를 APA-style traceability로 갱신했고, regression은 기존CVE-2026-71852/71870과 신규 3건 모두 repository-wide suppression 대상이 아님을 고정합니다. 현재 strictPdfReaderpath에서 각 advisory가 반드시 reachable하다고 과장하지 않습니다.sibling consolidation
#786@842e12485827c6f27a52eef997fc4e18f8865741의 유효 pypdf declaration/lock/security intent는 이 lineage에 승계했습니다. 근거 없는 upload-read chunk 성능 실험과 no-op retrigger doctrine은 승계하지 않았습니다.#803@7d688fbf659a65faab8c1eb7c233243f920e29d7의 유효 delta인language/modemax_length=50, 두 51-character 422 regressions, CHANGELOG 의미는 포함합니다.max_length자체가 pre-parser memory exhaustion을 막는다는 global Sentinel doctrine은 결함이므로 승계하지 않습니다.#774@26f99339076c3d43913f62739fe4482a6fe19224의 유효 delta도 이 exact head가 완전히 승계합니다: 동일 form bounds, 동일 focused 422 regression contract, protected-base Sentinel 복원, 더 강한 boundedpypdf>=6.16.2,<7.0declaration/lock/doctoring, 그리고 실제 pre-parser request-body control까지 포함합니다. #774의pypdf>=6.16.0무상한 declaration과 stale/과장 설명은 승계 대상이 아닙니다.Promotion boundary
모든 source/doc/test 변경은 predecessor CI evidence를 무효화합니다. 새 exact head의 required tests/security/code-scanning/review evidence가 terminal GREEN이고 unresolved thread가 없으며 independent current-head review가 성립하기 전에는 Ready/merge-ready로 올리지 않습니다. Self-approval, administrator bypass, gate weakening, no-op retrigger, force push, destructive rebase는 사용하지 않습니다.