[
https://issues.apache.org/jira/browse/PDFBOX-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468183#comment-15468183
]
Petras commented on PDFBOX-3065:
--------------------------------
[~tilman], yes I also noticed that signStream was not being closed in old code.
Was not sure whether it was left intentionally or by mistake, therefore
hesitated to include it. I just noted in JavaDocs for
COSWriter#getDataToSign()}} and {{ExternalSigningSupport#getContent()}} that
obtained stream must be closed after use. Probably it is not enough and stream
must always be closed in SigningOptions.
bq. Test missing for external signing (but I tried and it works fine)
As there were no tests for signing scenarios at all (I understand, that it is
not that trivial to make them), I didn't created either, just updated the
CreateSignature example. As it's going to be accepted, that means I have to
create one :)
bq. SigningSupport should better not be public, but probably must because in
different package
Yes, I really wanted to make it package private, but keeping it in different
package didn't allowed me to do that. Maybe it makes sense to refactor it as an
inner class of PDDocument, what do you think?
bq. You're using COSFilterInputStream in getDataToSign() while the old code
just used a byte buffer. I assume you did this to lessen the memory footprin
I was a bit confused why in the old code the new array is always created for
the data to be signed while PDFBox already has a feature to take the byte range
data with COSFilterInputStream and indeed keeps lower memory footpirint.
Therefore I reuse it (we similarly use it also in our tool, no problem so far).
bq. COSFilterInputStream has int parameters (harmless in COSWriter, as the
incremental part is small, but not in PDSignature)
Well, that's indeed a bit confusing point. PDSignature accepts byte range as
array of ints. Probably, following the ISO 32000-1, which defines Signature
Dictionary entry *ByteRange* as "an array of pairs of integers". Integers in
PDF are in range \[-2,147,483,648; 2,147,483,647], while "the size of a file
shall be limited to 10E10 bytes (approximately 10 gigabytes)". That infers that
the part that can be signed is much lower than the maximum size of PDF file...
> Right now PDFBOX does not permit to sign multiple files while calling an
> external signing service.
> --------------------------------------------------------------------------------------------------
>
> Key: PDFBOX-3065
> URL: https://issues.apache.org/jira/browse/PDFBOX-3065
> Project: PDFBox
> Issue Type: Improvement
> Components: Signing
> Affects Versions: 1.8.10
> Environment: Any Operating systems.
> Reporter: Andrea Paternesi
> Labels: features
> Fix For: 2.0.3, 2.1.0
>
> Attachments: PDFBOX-3065_viaExternalSigningSupport_v2.patch,
> PDFBOX-3065_viaExternalSigningSupport_v3.patch,
> PDFBOX-3065_viaExternalSigningSupport_v4.patch
>
>
> Since to sign a PDF you forced the implementation of the SignatureInterface
> interface, is not possible to prepare N hashes from N PDF files and then send
> them to a signing service that accepts multiple hashes with a single signon.
> For example if I use an OTP signing service.
> What would be nice to have is to separate the hash calculation from the
> signing.
> Instead to implement the Interface I would like to have something like this:
> 1) calculate hash from document with the new signature dictionary bytes
> 2) sign the hash
> 3) insert the signature into pdf
> This way I could achieve to sign for example 100 pdf files calling the
> service once.
> Right now must ask the user to sign in 100 times.
> Thanks in advance.
> Andrea.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
