Skip to content

FreePDF 7.6.0

Choose a tag to compare

View all tags
@christianz christianz released this 04 Nov 20:48
v7.6.0
7bf9031
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

FreePDF 7.6.0

FreePDF 7.6.0 signs a form's existing, empty signature field, such as a "sign
here" field, instead of always adding a new field next to it.

Packages

dotnet add package io7.FreePDF --version 7.6.0
dotnet add package io7.FreePDF.Layout --version 7.6.0

New

  • Signing an existing signature field. Name the field in
    DigitalSignatureOptions.FieldName:

    using var document = PdfReader.Open("form.pdf", PdfDocumentOpenMode.Append);
DigitalSignatureHandler.ForDocument(document, signer,
    new DigitalSignatureOptions { FieldName = "Approval", Reason = "Approved" });
document.Save("signed.pdf");
    • The signature becomes the field's value and is drawn in its widget at the
      widget's size; leave Rectangle and PageIndex unset. A field without area
      gives an invisible signature.
    • The field keeps its name and flags. The page and the form's field list stay
      as they are: the form gets no new field.
    • A field lock (/Lock) is recorded in the signature as a FieldMDP reference,
      as Acrobat and pyHanko record it, so validators lock the fields it names from
      then on. A lock with a document permission (/P) passes it on.
    • Required seed values (/SV) are checked. A required reason must be given as
      Reason; where the field allows none (no reasons or a single "." listed), no
      reason may be given and the signature has none. Requirements FreePDF cannot
      meet or check throw NotSupportedException: a signing certificate, a digest
      method, a timestamp, a certification, revocation information, locking the
      document or a named appearance. Optional seed values are ignored.
    • Mistakes throw when the handler is created: no field of that name, not a
      signature field, a field with fields below it, a field that is already
      signed, a lock without a valid /Action, or unmet seed values.
    • In Append mode the signature rules of 7.5 apply: a certification with
      "form filling and signing" (P=2) or more allows signing an existing field,
      "no changes" (P=1) refuses it, and a field that an earlier signature locks is
      refused when saving. It works in Modify mode too.

Upgrading from 7.5.x

Update all FreePDF packages to 7.6.0 together and rebuild; the assembly version
is now 7.6.0.0. The public API gains DigitalSignatureOptions.FieldName; nothing
else changes, and signing without FieldName adds a new field as before.

pyHanko's default policy accepts signing an existing field when the field is its
own widget, as pyHanko and most tools make them. When the field's widget is a
separate object, or it has several widgets or shares its appearance with another
widget, pyHanko reports the document's earlier signatures as changed; pyHanko's
own signer fails the same way on a shared appearance, refuses fields with several
widgets, and does not update a separate widget's appearance.

Validation

All 7.5.2 release gates apply, plus:

  • 35 regression tests: a field that is its own widget, one with a separate widget
    whose "sign here" appearance is replaced, an invisible field, swapped widget
    rectangles, Modify mode, the mistakes above, a lock recorded and then enforced
    on the next save, a lock with /P, each certification level, a field locked by
    an earlier signature, seed values including the reason conventions, and the
    custom appearance; 641 regression tests in all;
  • pyHanko 0.29.1: forms that pyHanko made with an empty signature field, signed by
    FreePDF in Append mode with the field count unchanged. A plain form, a form
    with a lock on another field, forms with a required reason or with no reason
    allowed, and a form certified with P=2 are VALID (the certification as "signing
    and form filling", also in poppler's pdfsig); P=1 and a disallowed reason are
    refused. After pyHanko changed the locked field, it judged FreePDF's signature
    INVALID, while the same change without the lock stayed VALID;
  • an independent review in two rounds, whose findings were fixed before release.
    It found locks, including /P, enforced by FreePDF and pyHanko, encrypted
    Append documents (AES-128 and AES-256) signed correctly, and the path that
    adds a new field unchanged.

The attached packages are the verified CI artifacts from source revision 7bf903164dfc351060083052357747960db4ce85, and the same files that were
uploaded to NuGet.org. SHA256SUMS and validation.json record their hashes and package-install evidence.
NuGet.org adds its repository signature, so a package downloaded from NuGet.org has a different hash from the attached file.

CI: https://github.com/io7/FreePDF/actions/runs/41905216827 (core),
https://github.com/io7/FreePDF/actions/runs/41905216799 (packages/API/independent checks),
https://github.com/io7/FreePDF/actions/runs/41905216762 (comparisons),
https://github.com/io7/FreePDF/actions/runs/41907475660 (NuGet publication).

Assets 10
Loading