build(deps): bump pypdf from 6.15.0 to 6.16.1 in /worker - #156
dependabot[bot] wants to merge 4 commits into
Conversation
Bumps [pypdf](https://github.com/py-pdf/pypdf) from 6.15.0 to 6.16.1. - [Release notes](https://github.com/py-pdf/pypdf/releases) - [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md) - [Commits](py-pdf/pypdf@6.15.0...6.16.1) --- updated-dependencies: - dependency-name: pypdf dependency-version: 6.16.1 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
|
建议先跑一遍测试，确认 pypdf 升级后没有兼容性问题再合并。 |
|
@dependabot rebase |
|
Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry! If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request |
PeterGuy326
left a comment
PeterGuy326
left a comment
There was a problem hiding this comment.
Independent review: the diff is limited to the pypdf requirement and uv lockfile. The lockfile remains internally consistent (uv lock --check passed locally), the Worker CI is green, and the upstream release notes include the intended PDF robustness/security fixes. Approving for squash merge.
|
Not a review vote and not an acceptance. I cannot cast a usable approving review on this PR: the two Status (live read, 2026-09-08, re-read before posting)head This changed since I started the review: One ordering caveat, because it is easy to lose a ticket by accident. I have one verified instance of the dismissal half of that: on The bump itself is sound, and CI covers it at execution level
1. The floor is unbounded, and what gets installed is still two upstream SEC releases behind
Both SEC entries are the same hardening class as the three advisories this PR exists for (bound a parser input limit), and neither has a GHSA allocated. Re-read just now: Measured with the CI-pinned uv
So getting to 6.18.0 is one deliberate command, not a re-resolution gamble. It is also where any hand re-lock would end up anyway: uv resolves the newest release satisfying a floor, not the floor. Starting from main's lock with only the Suggest taking the floor as written and letting the lock go to 6.18.0 in this PR — one PR, one CI run, and the installed pin lands on what upstream currently ships. If 6.16.1 merges instead, the installed pin stays two SEC hardenings short until someone re-locks by hand, because no alert is going to schedule that for us. One migration detail checked because it is the only thing that would make 6.18.0 more than a version bump: 6.18.0 reworks how default-limit overwrites are expressed ( 2. The other 98 lock lines are uv's own doing, not dependabot's — and I retract my first guessMy first hypothesis was that a newer uv than the repo pin had written that lock. I disproved it with the pinned tool. In a sanitized environment (no mirror/proxy env vars — that detail matters, see below) with uv
This PR's lock diff is 104 lines (52 removed + 52 added; the 53rd pair is the The env pitfall, so nobody else loses time on it: the first attempt inherited Minor, and explicitly not a defect of this PR
What I did not doDid not approve/request-changes, did not merge, did not close, did not touch any ref, did not click |
|
Superseded by #188 which raises the pypdf floor to 6.18.0 (covers this 6.16.1 bump plus additional SEC fixes #4047/#4055). Closing to avoid duplicate review. |
|
Superseded by #188 (raises pypdf floor to >=6.18.0). |
|
Holding this PR — not closing it, and the existing approval stands. Why it is on hold#188 targets the same two files ( 6.18.0 additionally carries two upstream
Both bound an unbounded parser input, and the surface is the untrusted one: So merging this first would mean immediately needing #188's change anyway, on a manifest whose stated floor would then be What happens next#188 has been marked ready for review and queued. Once it lands, this PR gets closed as subsumed, with the alert coverage confirmed against the resulting If #188 is declined — on the release-cadence question of whether 6.17.0/6.18.0 belong in this repo's Worker at all, which is a legitimate call for the owner to make — then this PR proceeds on PeterGuy326's existing approval of head To be explicit about what is not happening: no ref on this PR has been moved, no approval dismissed, and this is not a judgement that the Dependabot PR was wrong. It was correct when opened. #188 simply reaches further. |
### Not a review vote, and not an acceptance I am the author of this branch, so under this org's `require_code_owner` + `require_last_push_approval` configuration my own ticket cannot be the one that clears it. Nothing here asks for a merge, a close, a label, or a tag. The commitment is only: here is a change, here is what I measured. Supersedes nothing by itself: **#156 is a separate, still-valid Dependabot PR.** See *Sequencing* below. ### What changes Two files, +39/−39: - `worker/pyproject.toml:31` — `"pypdf>=4.0"` → `"pypdf>=6.18.0"` - `worker/uv.lock` — `pypdf 6.15.0 → 6.18.0`, nothing else moves That is the whole diff. No test, no docs, no CI file, no `CHANGELOG.md` entry: `grep -i 'pypdf\|numpy\|torch\|dependabot' CHANGELOG.md` on `main` returns **zero** dependency-bump entries across its 381 lines, and #156 is 2 files too, so an entry here would be inventing a convention. ### Why the floor is written `>=6.18.0` and not `>=6.16.1` Three open Dependabot alerts name `pypdf` in this lock — `#71` (`GHSA-jp53-mhqp-8xcg`, `< 6.16.0`), `#72` (`GHSA-763m-79hh-57f2`, `< 6.16.1`), `#73` (`GHSA-23w6-3w8w-8484`, `< 6.16.1`). This satisfies all three, the same as #156, once it is on the default branch. It additionally takes two upstream releases that **have no advisory**, so no alert will ever schedule them: - **6.17.0** (2026-09-04) — `Security (SEC): Limit value for Roman numerals (#4047)` - **6.18.0** (2026-09-07) — `Security (SEC): Limit allowed length of indirect object tokens (#4055)` Re-measured for this PR: `GET /advisories?affects=pypdf` → **43** entries, all `type: reviewed`, and the newest `first_patched_version` anywhere in that set is **6.16.1**. Both new entries are the same hardening class as the three above (bound an unbounded parser input), and the surface is the untrusted one: `worker/mem_worker/processors/pdf.py:79` runs `PdfReader(BytesIO(file.data))` on **user-uploaded** files. Writing the floor at 6.18.0 rather than letting the lock alone carry it is the part that survives a from-scratch resolve. Measured: **uv resolves to the newest release satisfying a floor, not to the floor** — `>=6.16.1` re-resolved today lands on 6.18.0, and after the next release it would land past it, in a manifest whose stated requirement was never 6.18.0. ### Evidence All of it executed on a tarball of `main @ 2986fe3` whose tree was proved equal to the remote (`.commit.tree.sha` `f447ca554377e85ba26090d59882b8d4f2b78731` == `git init && git add -A && git write-tree`), with the tool CI pins — uv `0.9.27` (`ci.yml:185-187`) — in a sanitized env (no mirror/proxy variables; `uv lock` through a mirror-configured uv rewrites thousands of URL lines and its "lock is stale" verdict is then worthless). | # | check | result | | --- | --- | --- | | 1 | `uv lock` on the **untouched** tree | **0 diff lines** vs committed `worker/uv.lock` — the pin is reproducible, so everything below is about the resolve, not a stale tool | | 2 | `uv lock` after only the constraint edit | `Updated pypdf v6.15.0 -> v6.18.0`, 76 lock lines | | 3 | name/version pairs, both locks | 85 packages each, **exactly one** difference: `pypdf 6.15.0 → 6.18.0` | | 4 | `uv lock --locked` | `rc=0` — so the Worker leg's `uv sync --frozen` (`ci.yml:193`, `UV_FROZEN: "1"` at `:170`) accepts it | | 5 | dist hashes vs the registry | sdist `ae58b7d93c22c169ffb02c3b06321c45c4f223b4916536568adb57d789d95d01`, wheel `05b762b77bcb9dcb4a7c91fcf5dded585b25bee7269ab3d3001d7c55fa1b324b` — byte-identical to `pypi.org/pypi/pypdf/json` | | 6 | the repo's own fixture (`test_processor_logic.py:419`) extracted at 6.15.0 / 6.16.1 / 6.18.0 on **Python 3.11** (`ci.yml:182`) | identical `page_count`, identical `sha256(extracted_text)` (`46e7c072b2684841…`, 214 chars), `"1800 RMB" in text` true on all three, malformed input raises the same `PdfStreamError` on all three | | 7 | 6.18.0's only behavioural change (`DEP: Rework configuration value handling (#4044)`) | `grep` over the whole tree for `overwrite_configuration` / `apply_configuration` / `disable_legacy_handling` / `pypdf.constants` → **0 hits**; `pypdf` appears in only 3 files (`worker/pyproject.toml`, `worker/mem_worker/processors/pdf.py`, `scripts/seed_demo_data.sh`) | Checks 1–4 and 7 are the ones CI cannot shortcut; 6 is the one that says "the worker's PDF path behaves the same", and 4 is the one that says "this lock is self-consistent". The Worker test leg on the exact head remains the real proof of the full pipeline (`test_processor_logic.py:457`) — **that runs in CI, I did not run it here**; the local venv has none of the Worker's own dependencies installed. About the diff size: of the 76 changed lock lines, **8 are pypdf** (specifier, version, sdist, wheel — each on both sides). The other 68 are uv's marker renormalisation: the `python_full_version >= '3.15' and sys_platform == 'darwin'` fork marker hopping between `torch 2.13.0` and `2.13.0+cpu` (likewise `torchvision 0.28.0` / `+cpu`), `python_full_version` narrowing dropping off `numpy` / `scipy` / `tifffile`, and the `resolution-markers` list reordering. That is not avoidable churn I chose: **a plain `uv lock` on either side of a pin costs 0 lines, but any resolve that moves pypdf pays them** — #156's own `+53/−53` is the same shape. No other package's *version* changes. ### Process: this PR is ahead of its issue's readiness gate `AGENTS.md` rule 2 says not to implement a material change until its issue has acceptance criteria and `status:ready`. Refs #187, which I filed with the AC list and reproduction steps for exactly this; it is `status:needs-triage`, and `status:ready` is a maintainer's label, not mine to set. So this is a **draft**, and undrafting it is the step that should follow that label rather than precede it. If triage would rather the change go in behind #156, #187 can simply wait. ### Sequencing with #156 Both branches touch the same two files, so they will conflict with each other, not with `main`. - If **#156 merges first**: rebase this onto the new `main` — the manifest line is a one-token edit and the lock is one `uv lock` with the pinned tool. I offered to do that; it is not something to do unasked. - If **this merges first**: #156's diff is a strict subset of this one and its three alerts are dismissed by this branch instead. **I am not asking for #156 to be closed** — it has an in-force `APPROVED` from `PeterGuy326` on its current head and I am not in a position to spend someone else's ticket. That call, and the release-cadence call about whether 6.17.0/6.18.0 belong in this repo's Worker at all, is the owner's. ### What I did not do No review submitted, no vote, no merge, no close, no label change on anything except the new issue's own labels, no ref moved on #156, no `Update branch` clicked anywhere, no `CHANGELOG.md` edit, no tag, no publish. Co-authored-by: waterbro-8 <318569545+waterbro-8@users.noreply.github.com> Co-authored-by: 修雨 <47820304+PeterGuy326@users.noreply.github.com>
|
Closing as subsumed by #188, which merged as The alert coverage I said I would confirm against the resulting
All three alerts this PR would have cleared are cleared by What #188 delivered beyond this PR's scope: the manifest floor is To be clear about what this closure is not: it is not a judgement that this PR was wrong. It was correct when Dependabot opened it on 2026-09-02, it carried an in-force approval from PeterGuy326 on head PeterGuy326's approval was not spent on a merge, and no ref on this branch was moved before closing. The one remaining dependency gap in this repository is unrelated: three open |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
3 participants
Bumps pypdf from 6.15.0 to 6.16.1.
Release notes
Sourced from pypdf's releases.
Changelog
Sourced from pypdf's changelog.
Commits
1bce7a7REL: 6.16.1d91ab70SEC: Limit iterations for outline retrieval and XForm text extraction (#3966)2b60c99REL: 6.16.0c9ba557SEC: Detect cycles in TreeObject.insert_child (#3964)c8e1c72BUG: Always define PdfWriter._reader (#3960)3a0f355ROB: Detect cyclic pages in _get_page_in_node (#3962)20512f4ROB: AppearanceStream: Only escape parentheses for 8-bit fonts (#3961)34ccd14MAINT: Deduplicate CatalogAttributes and CatalogDictionary (#3940)5b8f19eENH: AppearanceStream: Allow arbitrary rotations and apply rotations for anno...53bfbc6PI: Build /ToUnicode source-code bytes directly in parse_bfrange (#3952)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.