Repository navigation
chore(deps): bump pypdf from 6.16.1 to 6.19.0 in /envs/repl_env - #1300
Conversation
Bumps [pypdf](https://github.com/py-pdf/pypdf) from 6.16.1 to 6.19.0. - [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.16.1...6.19.0) --- updated-dependencies: - dependency-name: pypdf dependency-version: 6.19.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
Dependencies
python:uv
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Alignment Review Report
Automated Checks
- Lint: N/A for this diff — only
envs/repl_env/uv.lockchanged, and TOML/lockfiles aren't linted byruff/usort. (lint.shdoes exit non-zero, but only due to ~55 pre-existing reformat candidates elsewhere inenvs/**/src/**unrelated to this PR;envs/repl_env/runner.pyhas one pre-existing unused-import nit, also unrelated to this diff.) - Debug code: CLEAN —
check-debug.shonly scanssrc/, which this PR doesn't touch.
Open RFCs Context
Scanned all RFCs in rfcs/ (000, 001, 002, 003, 004, 005, 006, 008, 010, 011, 012 — several In Review/Draft). None cover packaging, dependency management, or the PyPI index, so there's no RFC-governed surface this change touches.
Tier 1: Fixes Required
None. This is a clean, lockfile-only dependency bump:
pypdfis a direct dependency ofenvs/repl_env(used server-side only, in the Gradio/webtab, to parse user-uploaded PDFs viaPdfReader(...).pages[i].extract_text()— seeenvs/repl_env/server/gradio_ui.py:146).envs/repl_env/pyproject.tomlfloor (pypdf>=6.16.1) already permits 6.19.0, so dependabot updated the lock only (version/sdist-hash/wheel-hash ofpypdf), leaving the floor unchanged.uv lock --check --project envs/repl_envpasses (121 packages resolved).- Lock was already "born-clean" at base (
revision = 3, 0registries.huggingface.techrefs, allpypi.org/simple) and stays clean — no index-flip or revision-bump side effects. Diffingfiles.pythonhosted.orglines confirms only thepypdfartifact URLs/hashes changed; I independently verified both hashes againstpypi.org/pypi/pypdf/<version>/jsonand they match exactly. - Security-positive:
pypdf6.16.1 currently carries 8 distinct DoS CVEs (CVE-2026-102993…103000 — memory/CPU-exhaustion issues in page-label,/ToUnicode, indirect-object, appearance-stream, font, FlateDecode, and embedded-file parsing), all fixed across 6.17.0–6.19.0. 6.19.0 has 0 known vulnerabilities on PyPI. Since this code path parses untrusted user-uploaded PDFs, this is a meaningful hardening update.
Tier 2: Alignment Discussion
Principle Conflicts
None identified. No reward computation, client-server boundary, or MCP surface is touched.
RFC Conflicts
None identified. No open RFC covers dependency/packaging management.
Process note (recurring, non-blocking)
ALIGNMENT FLAG: Native dependabot PR bypasses dependabot.yml exclude-paths
- Principle/RFC at stake: N/A (process/tooling, not a design principle) —
.github/dependabot.yml'suvecosystem entry setsexclude-paths: ["envs/**"], intending env-leveluvbumps to flow through the aggregatedcodex/dependabot-envs-*roll-up PRs instead. - The concern: This PR is a native
dependabot/uv/envs/repl_env/pypdf-6.19.0branch that editsenvs/repl_env/uv.lockdirectly, which theexclude-pathsconfig was meant to prevent. This appears to be a long-standing platform limitation where theuvpackage ecosystem doesn't honorexclude-pathsthe way other ecosystems do (observed repeatedly on priorenvs/repl_envpypdf bumps). Not a correctness issue with this specific bump — just a recurring config/process mismatch worth revisiting. - Suggested reviewer: @burtenshaw (author of the
dependabot.ymlexclude-paths config)
Also non-blocking: the pypdf>=6.16.1 floor in pyproject.toml still technically permits resolving the now-fully-vulnerable 6.16.1 on a non-frozen install; the committed lock + --frozen deploy keep actual risk low, but raising the floor to >=6.19.0 would make the security intent explicit (same note made on the prior 6.14.2→6.16.1 bump).
Summary
- 0 mechanical issues to fix
- 0 alignment points for human review (no principle conflicts)
- 0 RFC conflicts to discuss
- 1 non-blocking process note (recurring exclude-paths bypass, cc @burtenshaw) + 1 non-blocking suggestion (raise pyproject floor to match the security fix)
Sent by Cursor Automation: Pre-review
| [[package]] | ||
| name = "pypdf" | ||
| version = "6.16.1" | ||
| version = "6.19.0" |
There was a problem hiding this comment.
Verified: pypdf 6.16.1 → 6.19.0. Both sdist/wheel hashes match pypi.org/pypi/pypdf/<version>/json exactly. 6.16.1 has 8 known DoS CVEs (CVE-2026-102993…103000, all in PDF-parsing code paths); 6.19.0 has 0. Security-positive given pypdf here parses untrusted user-uploaded PDFs server-side (envs/repl_env/server/gradio_ui.py:146). Lock is lockfile-only (pyproject floor >=6.16.1 already permitted this version) and stays "born-clean" (revision 3, all pypi.org/simple) — uv lock --check passes.
Co-authored-by: benjamin.burtenshaw <benjamin.burtenshaw@huggingface.co>
Co-authored-by: benjamin.burtenshaw <benjamin.burtenshaw@huggingface.co>
Bumps pypdf from 6.16.1 to 6.19.0.
Release notes
Sourced from pypdf's releases.
... (truncated)
Changelog
Sourced from pypdf's changelog.
... (truncated)
Commits
d62cb58REL: 6.19.00d8b5a8SEC: Limit size of alphabetical page labels (#4096)959467aPI: Move static value out of loop body for appearance stream data (#4087)20822b2DEV: Bump zizmorcore/zizmor-action from 0.6.3 to 0.6.4 (#4093)25f2301DEP: Replace PdfWriter method add_js (#3979)a924438BUG: Do not copy unrelated pages when appending pages with non-terminal field...cf5cec2BUG: Use page reference for existing internal link targets (#4076)96d81f0BUG: Arabic-Indic digits are reversed during text extraction (#4077)2d21901DEV: Fix Color class for latest mypy (#4082)893a010MAINT: Split PdfDocCommon._flatten (#4070)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.
Note
Low Risk
Lockfile-only dependency bump; improves PDF parser safety for user uploads with no direct code changes, though behavior of malformed PDFs may differ slightly.
Overview
Updates the
envs/repl_env/uv.lockpin forpypdffrom 6.16.1 to 6.19.0 (still within the existingpypdf>=6.16.1constraint inpyproject.toml). No application code changes.This refresh pulls in upstream security hardening and bug fixes for PDF parsing—relevant because the REPL Gradio tab uses
pypdf.PdfReaderserver-side on uploaded documents. Notable upstream changes include limits on alphabetical page labels and stricter parsing bounds (e.g. FlateDecode, font/Widths), plus fixes for text extraction and page/link handling.Reviewed by Cursor Bugbot for commit 80d3fa2. Bugbot is set up for automated code reviews on this repo. Configure here.