Relationship to PyPDF2

[MartinThoma]

Hi, I'm the new maintainer of PyPDF2 👋

Some PyPDF2 users want to digitally sign PDFs - which seems to be supported by pyHanko.

I was now wondering if it makes sense for PyPDF2 to integrate that feature or if we can just reference to pyHanko. The workflow for the user could be to manipulate the PDF in the desired way with PyPDF2, save it, and then sign it with pyHanko. Would there be any disadvantage?

Another thing I wanted to point out is that the newly created https://github.com/py-pdf GithubOrganization might also be a good place for pyHanko. It might lead a bit more attention to pyHanko. Let me know what you would think about this :-)

[MatthiasValvekens]

Hi @MartinThoma,

Thanks a lot for reaching out!

Good to hear that someone's picked up PyPDF2. As you might've noticed in the README, I started this project by forking a subset of the (at the time, unmaintained) PyPDF2 codebase---it's been massively refactored since, but PyPDF2 provided me with a significant headstart back when I started out, and I'm grateful for that.

Now, with regard to the matter at hand: pyHanko is a library that specialises in signing-related tasks (and document encryption, but that's arguably not nearly as important). It doesn't try to be a general-purpose PDF manipulation toolkit, and that was a conscious choice:

• PDF signing and (especially) signature validation require low-level access to PDF file structure that is not required in "regular operation", and comes at a bookkeeping/performance cost.
• PDF signature validation is hard, and both implementation and maintenance require quite a bit of niche knowledge about the file format and the way signatures are used in the wild. My forked PDF parser is also quite a bit stricter (by default) than a general-purpose PDF parser for that reason.
• While implementing basic signature creation using in-memory/on-disk key material is pretty easy (you could probably work that into PyPDF2 in an afternoon), there's a certain baseline level of complexity that you have to support for the implementation to be useful in practice.

Here's a non-exhaustive list of often-overlooked things that you (arguably) need even if you don't care about signature validation:

• You need support for generating incremental updates to PDF documents, otherwise you can't operate on already-signed files at all, and in particular multi-signature workflows become impossible to implement. IIRC PyPDF2 doesn't have that at the moment.
• For serious applications, document signing keys are typically stored in hardware or accessed using remote APIs, i.e. you don't get direct access to the private key. That complicates things and also has performance implications.
• Users will expect there to be some kind of mechanism to generate visual appearances for signatures.
• To ensure signatures remain validatable over long timescales, you need to be able to query & embed OCSP responses, CRLs, timestamp tokens, etc.

Finally, there's the fact that the PDF landscape has changed quite a bit since 2008, when PDF 1.7 was standardised as ISO 32000-1. Not only is there a PDF 2.0 spec now (ISO 32000-2), but also various "satellite" standards relating to PDF signing have popped up in the meantime: PAdES (+ national variants thereof); soon we'll also have extensions to algorithm usage stemming from ISO/TS 32001, ISO/TS 32002... Somebody needs to stay on top of all that. Granted, I'm biased because I'm directly involved with PDF standards development efforts, so maybe take that with a grain of salt.

---

Briefly put, my position is the following: keeping the signing stuff in one place, in a separate, single-issue library, is better for everyone involved. If you would like to add digital signing features to PyPDF2, I would strongly recommend adding this project as an optional (!) dependency to PyPDF2 instead of trying to roll your own implementation.

Of course, since pyHanko is MIT-licenced, you're welcome to recycle bits and pieces and upstream those into PyPDF2---as long as you abide by the licence terms, go wild! All I'm saying is: developing and maintaining a good digital signing toolkit is not as easy as it sounds ;).

As for moving to the py-pdf org: give me some time to think about it :) .

[MartinThoma]

Thank you for the detailed answer!

keeping the signing stuff in one place, in a separate, single-issue library, is better for everyone involved.

That was also my gut feeling 👍

If you would like to add digital signing features to PyPDF2, I would strongly recommend adding this project as an optional (!) dependency to PyPDF2 instead of trying to roll your own implementation.

At the moment, it looks to me that they could be developed completely independently. That is good as it gives us maintainers and the users more flexibility.

Just in case anybody notices that there is unnecessary friction in combining both libraries: Feel free to contact me (e.g. by opening an issue).

I'll give people a week to think about it, but I think I'll close that request a "out of scope" for PyPDF2.

[MatthiasValvekens]

No worries; I'm always happy to discuss further, and my opinion is not set in stone. If necessary, feel free to tag me in discussions on your end and/or direct people to this forum. :)