[
https://issues.apache.org/jira/browse/PDFBOX-4997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217738#comment-17217738
]
Michael Klink commented on PDFBOX-4997:
---------------------------------------
{quote}thanks for analyzing and fixing this{quote}
I hope the proposed fix does work as desired in general.
In my test {{testSignSigned000}} in
[CreateSignature|https://github.com/mkl-public/testarea-pdfbox2/blob/master/src/test/java/mkl/testarea/pdfbox2/sign/CreateSignature.java#L751]
the fix does work properly (object 54 is not copied unnecessarily to the
incremental update anymore and nothing else goes wrong), but I cannot claim to
know the whole saving apparatus of PDFBox well enough to preclude unwanted side
effects.
{quote}I wonder how the problem you mention could appear, or why it didn't.
Maybe PDFs with the same COSName as different objects?{quote}
I assume the questionable situations are too seldom or the effects are too
diffuse to be ascribed to the incremental update mechanism.
If I had too much time to spare, I'd try too construct an example file
visualizing the effect (or fail doing so if the smell turned out to be a mere
phantom smell), but I'm afraid there is too much else to do...
> 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: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
