ENH: add sign command

[moormaster]

• adds sign command to create signed pdfs using a PKCS12 .p12 key
• integration of fdpf2 lib is possible but not in a "clean and documented" way
  The annotation for the signature needs to calculate its hash value from the contents and the certificate. When using fpdf2 no contents are present in the newly created FPDF instance. To sign the contents from an existing pdf some magic must be done:
  • In OutputProducer.bufferize() - output.py:877 the signing of the contents needs to be suppressed / deferred until the actual pdf contents have been merged.
    -> _sign_key = None is set before serializing the FPDF instance.
  • After merging signing is done by using an fpdf-internal method fpdf.sign.sign_content() - sign.py:45 which replaces the placeholders in the signature annotation
  • PdfWriter() alters the placeholders inside of the signature annotation.
    -> For sign_content() to succeed the placeholders must be search&replaced back into their original form how sign_content() expects them to look like
• unit test use signing-certificate.crt and signing-certificate.p12 taken from https://github.com/py-pdf/fpdf2

[Lucas-C]

Thank you very much @moormaster for working on this feature 👍

I made a few comments as feedback

[Lucas-C]

Could you also please add a mention of this new feature in CHANGELOG.md as part of this PR?

I'll answer your comments in a few hours, can't do it right now, but thank you for all your work on this 👍

[moormaster]

Could you also please add a mention of this new feature in CHANGELOG.md as part of this PR?

Added an entry to CHANGELOG.md and fixed commit message & PR title: FEAT -> ENH

[Lucas-C]

I think this is ready to merged, as soon as the CI pipeline is ✅ 🙂
It's currently failing due to a typing error on Generator[FPDF]:

E   TypeError: Too few arguments for typing.Generator; actual 1, expected 3

Good job really on this PR 👍

Also, have you tested signing a PDF and then sign it again with pdfly sign?
Does it fail? Does it produce a new PDF with a distinct signature?

[Lucas-C]

@allcontributors please add @moormaster for code

[allcontributors]

@Lucas-C

I've put up a pull request to add @moormaster! 🎉

[moormaster]

Also, have you tested signing a PDF and then sign it again with pdfly sign? Does it fail? Does it produce a new PDF with a distinct signature?

I guess this would currently generate a broken pdf - When fully generating a pdf with fdpf2 the fpdf.sign() method prevents itself from being called multiple times on the same document.

The sign command of pdfly should check for an existing signature annotation and refuse to add another signature in this case + another unit test to test this behaviour.

[moormaster]

I guess I might have fixed all the PR related CI failures. I did not focus on the python 3.8 pipeline since that python version already reached its end-of-life.

Added a unit test to ensure that attempts to sign an already signed pdf will be denied.

[Lucas-C]

I guess I might have fixed all the PR related CI failures. I did not focus on the python 3.8 pipeline since that python version already reached its end-of-life.
Added a unit test to ensure that attempts to sign an already signed pdf will be denied.

Great 👍
Regarding Python 3.8, I'm removing it from the test matrix in PR #171

[Lucas-C]

I'm rebasing the branch so that you benefit from the removal of Python3.8 & Python3.9 in the pipeline test matrix.

There's now just this single ruff error that's blocking:

 pdfly/sign.py:19:1: UP035 [*] Import from `collections.abc` instead: `Generator`
   |
17 | from contextlib import contextmanager
18 | from pathlib import Path
19 | from typing import Generator, Optional, Union
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ UP035
20 | 
21 | import fpdf.sign
   |
   = help: Import from `collections.abc`

[moormaster]

pdfly/sign.py:19:1: UP035 [*] Import from collections.abc instead: Generator

Fixed

[Lucas-C]

This new command has been included in the latest 0.5.0 release: https://github.com/py-pdf/pdfly/releases/tag/0.5.0