[
https://issues.apache.org/jira/browse/PDFBOX-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853592#comment-16853592
]
Tilman Hausherr commented on PDFBOX-4554:
-----------------------------------------
That is even more change and is getting to into a moving target. We'd be
required us to compute the hash ourselves (probably need to find out what
algorithm is used first), and the idea of using BouncyCastle was to let "them"
doing the actual work. Their javadoc is very poor and often not existent but
they do a good job.
Btw for your digest calculation you don't need the byte buffers and
{{getSignedContent()}} at all. You could just use the original array with the
offset and lengths from byteRange.
However {{ShowSignature.verifyPKCS7}} then can't be used anymore as it is now.
Its first parameter is sometimes a hash and sometimes the PDF (minus the
signature), because of different signature types and both work with the same
code BouncyCastle calls.
{quote}
Almost everywhere (outside of PDFBox) they are prepared to work with multiple
ByteBuffer or multiple byte[] -
{quote}
Who are "they"? Looking into the BouncyCastle code for
{{CMSProcessableByteArray}}, the byte array gets converted into a stream. Which
suggests that one could just create a stream that combines the two byte array
segments.
> operations taking a byte[] need to allow for offset and length too
> ------------------------------------------------------------------
>
> Key: PDFBOX-4554
> URL: https://issues.apache.org/jira/browse/PDFBOX-4554
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Jason Pyeron
> Priority: Major
>
> Without this, massive amounts of memory must be copied/allocated to "trim"
> byte[].
> See forthcoming pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
