Update pypdf to > 6.0 (CVE-2025-55197)

[Azurency]

Is it possible to bump the pypdf dependency to > 6.0 ? This would allow us to use a secure version of pypdf. Pypdf version prior to 6.0 is subject to CVE-2025-55197.

[DoomedJupiter]

Looks like pypdf > 6.0 only supports python >= 3.9, which would require camelot-py dropping support for python 3.8

[DoomedJupiter]

Digging a little deeper, I came up with the following...

camelot-py seems to use pypdf' in three places: handlers.py, io.py, and utils.py. In particular, we import pypdf._utils.StrByteType, pypdf.PdfReader, and pypdf.pdfWriter.

In our project.toml we show requires-python = ">=3.8" even though this version is not listed in the classifiers section, yet we do still test against python 3.8, as shown in our .github/workflows/tests.yaml. Moreover, our project.toml locks the versions of pypdf to "pypdf>=3.17,<4.0; python_version < '3.12'" and "pypdf>=4.0,<6.0; python_version >= '3.12'".

Looking at the 4.0.0 change log for pypdf, I don't see why the lock "pypdf>=3.17,<4.0; python_version < '3.12'" is required.

Similarly, looking at the 6.0.0 change log, I don't see why the lock "pypdf>=4.0,<6.0; python_version >= '3.12'" is required. Note that pypdf 6.x supports back to python 3.9.

@bosd @MartinThoma Perhaps there is some deeper issue that requires these locks?

[Azurency]

I ended up creating a fork, updating that one line to pypdf>=4.0,<7.0; python_version >= '3.12', and rebuilding the uv.lock. It would be nice if this were done here, though

[mhattingpete]

@DoomedJupiter any news on this?

[a-klos]

any updates on this?

[eltemater]

Pypdf <6.0 is also prone to this very prevalent issue
py-pdf/pypdf#3419