build(worker): pypdf floor tracks only advisories; pin lags two SEC fixes #187

Activity

1. waterbro-8

   added

   type:maintenanceMaintenance, tooling, refactoring, or repository workMaintenance, tooling, refactoring, or repository work

   evidence:e2-sourceSource or log evidence identifies the likely causeSource or log evidence identifies the likely cause

   status:needs-triageAwaiting maintainer classificationAwaiting maintainer classification

   area:workerPython processing workerPython processing worker

   dependenciesPull requests that update a dependency filePull requests that update a dependency file

   on Sep 8, 2026
2. PeterGuy326

   added

   status:readyScope and acceptance criteria are ready for developmentScope and acceptance criteria are ready for development

   and removed

   status:needs-triageAwaiting maintainer classificationAwaiting maintainer classification

   on Sep 10, 2026
3. PeterGuy326 commented on Sep 10, 2026

   

   PeterGuy326

   on Sep 10, 2026

   Collaborator

   More actions

   Triage: readiness gate passed — applying status:ready

   Checked against every bullet of the readiness gate in docs/maintainers/triage.md:

   Gate requirement	Verdict
   not a duplicate, belongs in this repo	Pass. Distinct from #156, which is the Dependabot record for the three GHSA-patched releases; this one is about the two upstream SEC releases no advisory will ever schedule. Non-goal 2 states the separation explicitly.
   no sensitive/security details exposed publicly	Pass. Non-goal 1: the 6.16.x advisories are already public and the 6.17.0/6.18.0 entries have no CVE or GHSA, so there is nothing to route through SECURITY.md.
   type, area, status, evidence labels accurate	Pass. type:maintenance, area:worker, dependencies are right. evidence:e2-source is the strongest honest level and is being left as-is — the author executed the seven steps, but the policy reserves E3 for reproduction by someone other than the author. Confidence is not a substitute for that.
   bugs have a defensible severity	N/A. type:maintenance; the policy does not normally apply severity to maintenance.
   problem / desired outcome clear	Pass. The mechanism is stated precisely: an advisory-driven floor cannot express a pin that no advisory schedules, and uv resolves to the newest release satisfying a floor rather than to the floor, so the lockfile alone does not carry the intent.
   acceptance criteria objective and testable	Pass. AC-001…AC-005 are each measurable without judgement: a floor value, uv lock --locked exit code, a name/version pair-set diff, the Worker test leg on the exact head, and two literal SHA-256 dist hashes.
   scope and explicit non-goals recorded	Pass. Three non-goals, including the pre-existing darwin + Python >= 3.15 clip extra marker geometry, which is correctly excluded rather than silently absorbed.
   dependencies, compatibility constraints, material risks identified	Pass. The 68-of-76 lock lines that are uv marker renormalisation rather than pypdf are called out as unavoidable churn with the reason, and DEP: Rework configuration value handling (#4044) — 6.18.0's only behavioural change — is traced to zero consumers in this tree.
   a validation approach exists	Pass. Seven steps, each with the CI-pinned tool version (uv 0.9.27 at ci.yml:185-187), a sanitized env, and a tree equality proof against main @ 2986fe38.
   small enough for a reviewable PR	Pass. #188 is 2 files, +39/-39.

   Nothing here needed status:waiting-feedback; no bullet is missing information.

   Note on the attack surface, since it is what makes this more than housekeeping: worker/mem_worker/processors/pdf.py:79 runs PdfReader(BytesIO(file.data)) on user-uploaded files, and both 6.17.0 (Limit value for Roman numerals) and 6.18.0 (Limit allowed length of indirect object tokens) bound an unbounded parser input on exactly that path.

   Effect on #188

   #188 named this label as the only thing standing between it and being review-ready, and asked that undrafting follow the label rather than precede it. That ordering is now satisfied, so #188 is being marked ready for review.

   Leaving #188's Refs #187 as written rather than rewriting it to Closes — the author chose that keyword and it is their PR body. The consequence is only that this issue will not auto-close on merge, so it will be closed by hand against AC-001…AC-005 once #188 lands.

   Evidence stays at E2. Raising it to E3 needs a non-author to re-run the seven steps, and to E4 needs a non-author to verify AC-001…AC-005 on the delivered outcome.
4. PeterGuy326

   added a commit that references this issue on Sep 10, 2026

   build(worker): raise the pypdf floor and pin to 6.18.0 (#188)

   ...

   55d09b2
5. PeterGuy326 commented on Sep 10, 2026

   

   PeterGuy326

   on Sep 10, 2026

   Collaborator

   More actions

   Closing as completed. Delivered by #188, merged as 55d09b203ba9 (ordinary squash, no admin bypass).

   Every acceptance criterion re-checked against main after the merge rather than taken from the PR body:

   AC	Requirement	Verified on main
   AC-001	worker/pyproject.toml declares a floor at or above the newest upstream SEC release	Pass. worker/pyproject.toml:31 = "pypdf>=6.18.0". The floor is in the manifest, not only the lock, so a from-scratch resolve cannot land below it.
   AC-002	worker/uv.lock pins that version and uv lock --locked passes with the CI-pinned uv	Pass. worker/uv.lock:1646-1648 = name = "pypdf" / version = "6.18.0" / registry pypi.org/simple. The Worker leg runs uv sync --frozen with UV_FROZEN: "1", so a self-inconsistent lock would have failed it.
   AC-003	No other package's locked version moves	Pass on the author's measurement (85 name/version pairs each side, exactly one difference) and consistent with the merged diff of +39/-39 across 2 files. The other 68 lock lines are uv marker renormalisation, not version changes. I did not independently re-derive the pair sets.
   AC-004	The Worker test leg passes on the exact head	Pass. Worker check conclusion success on merge SHA 55d09b203ba9. This is the leg that actually executes the 6.18.0 extraction path at test_processor_logic.py:457.
   AC-005	The dist hashes in the lock match what the registry publishes for 6.18.0	Pass. worker/uv.lock:1649 sdist sha256:ae58b7d93c22c169ffb02c3b06321c45c4f223b4916536568adb57d789d95d01 and :1651 wheel sha256:05b762b77bcb9dcb4a7c91fcf5dded585b25bee7269ab3d3001d7c55fa1b324b — both byte-identical to the values recorded in this issue.

   Outcome on the alert stream, which is the thing this issue existed to get right:

   • Dependabot alerts feat(recall): orchestrate hybrid candidates, reranking, diversity, and budgets #71 (GHSA-jp53-mhqp-8xcg), feat(feedback): capture recall/use events and add an offline ranking loop #72 (GHSA-763m-79hh-57f2) and test(models): retain real-model evidence for local-fast-v2 and idealab-quality-v2 #73 (GHSA-23w6-3w8w-8484) all moved to state fixed at 2026-09-10T16:25:49-50Z. Zero pypdf alerts remain open in this repository.
   • The two releases no advisory would ever have scheduled are now in: upstream 6.17.0 (Limit value for Roman numerals) and 6.18.0 (Limit allowed length of indirect object tokens), both hardening the unbounded-parser-input surface at worker/mem_worker/processors/pdf.py:79 against user-uploaded files.

   #188 used Refs rather than Closes, so this did not auto-close; that is why it is being closed by hand.

   On the evidence label: this stays at evidence:e2-source and is not being raised. AC-001, AC-002, AC-004 and AC-005 above were verified by a non-author against the merged default branch, which is verification of the delivered outcome, but the seven reproduction steps in this issue were never independently re-run by a non-author, and docs/maintainers/triage.md reserves e3-reproduced for exactly that. Closing a delivered issue does not retroactively manufacture reproduction evidence.

   Non-goal 3 remains unaddressed and correctly so: the darwin + Python >= 3.15 unsatisfiable clip extra marker geometry is pre-existing on both sides of this bump and has no CI coverage. It needs its own issue if anyone wants it.
6. PeterGuy326

   closed this as completedon Sep 10, 2026