Bug 160270 - Please always write acroform entries as indirect referenced objects
Summary: Please always write acroform entries as indirect referenced objects
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: QA:needsComment
Keywords:
Depends on:
Blocks: PDF-Signature
  Show dependency tree / graph
 
Reported: 2024-03-19 08:49 UTC by Sune Stolborg Vuorela
Modified: 2024-04-03 03:14 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Stolborg Vuorela 2024-03-19 08:49:22 UTC 
Certain online signed pdf validators (like https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation ) has issues validating a later-signed document where the AcroForm entry is directly embedded into the Catalog. 

While I think this is technically a bug in the validation utility, it is probably not trivial to get fixed.

A simple workaround would be to always write the AcroForm element as a indirect referenced object.

It looks like LibreOffice always puts the AcroForm element directly in the Catalog dict, and thus all forms to be filled that gets a signature added cannot be validated by such tools.

When signing (and thus adding to the AcroForm element), the AcroForm element needs to be incrementally updated (PDF Spec 7.5.6), but the only way of doing it is to rewrite the entire 'Catalog' dict when it is embedded, and some validators seems to have issues with that.

See also https://bugs.kde.org/show_bug.cgi?id=482682 for where this comes from.