[
https://issues.apache.org/jira/browse/PDFBOX-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217700#comment-17217700
]
Tilman Hausherr commented on PDFBOX-4997:
-----------------------------------------
[[email protected]] snapshot here:
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.22-SNAPSHOT/
[~mkl] thanks for fixing this.
I wonder how the problem you mention could appear, or why it didn't. Maybe PDFs
with the same COSName as different objects?
> Incremental update adds certain objects not marked as needing update
> --------------------------------------------------------------------
>
> Key: PDFBOX-4997
> URL: https://issues.apache.org/jira/browse/PDFBOX-4997
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
> Affects Versions: 2.0.21, 3.0.0 PDFBox
> Reporter: Michael Klink
> Priority: Major
> Attachments: signed-000.pdf
>
>
> _This bug causes the eSignature DSS issue
> [DSS-2260|https://ec.europa.eu/cefdigital/tracker/browse/DSS-2260]._
> If during an incremental update an indirect object containing only a name
> object is checked for need of writing, it always is added to the objects to
> write and, therefore, eventually written to the update section.
> For example in the attached document {{signed-000.pdf}} each page has a color
> space resource entry *CS1* referring to the indirect object 54 containing
> only the name object, *DeviceGray*. Whenever a page is marked as needing an
> update, the bug causes object 54 also to be written even if it is not changed
> at all.
> While this seems like a minor annoyance only, it has serious repercussions:
> In multi-signature use cases this makes Adobe Reader claim previous
> signatures to be broken whenever a new signature with visualization is added
> using PDFBox, see also
> [DSS-2260|https://ec.europa.eu/cefdigital/tracker/browse/DSS-2260].
> ----
> The cause of the bug is
> {{org.apache.pdfbox.pdfwriter.COSWriter.addObjectToWrite(COSBase)}} where the
> following {{if}} clause attempts to determine whether the inspected object
> does not need to be written:
> {code:java}
> if (actual != null && objectKeys.containsKey(actual)
> && object instanceof COSUpdateInfo &&
> !((COSUpdateInfo)object).isNeedToBeUpdated()
> && cosBase instanceof COSUpdateInfo &&
> !((COSUpdateInfo)cosBase).isNeedToBeUpdated() )
> {
> return;
> }
> {code}
> Here {{cosBase}} contains the content of the indirect object, in the case in
> question the {{COSName}} *DeviceGray*. As {{COSName}} does not implement
> {{COSUpdateInfo}}, the condition never evaluates to {{true}}, so the flow
> never returns here but instead always continues with the following lines
> where the object is added to the collection of objects to write.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
