[jira] [Commented] (PDFBOX-3173) Signature dictionary is not decrypted in encrypted files
[
https://issues.apache.org/jira/browse/PDFBOX-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15072782#comment-15072782
]
Thomas Chojecki commented on PDFBOX-3173:
-
I've tried it but without success. At the moment we use the pdfbox 1.8.8 and
that version isn't capable to create a non broken document. Porting to 2.0.0
isn't possible without bigger refactoring. Maybe at the moment impossible,
because some features like PDPage to Image is missing and need to be
reimplemented.
So at the moment I can only offer verification with pdfbox 2.0.0.
PS:
I used this file for testing: FormI-9-English.pdf and the result is
http://people.apache.org/~tchojecki/Signed7189737479851398678.pdf
My code look something like this:
...
if (document.isEncrypted())
{
document.decrypt("");
document.encrypt("", "");
}
...
And this combination is the only one that produce a document at all and not
throwing exceptions.
> Signature dictionary is not decrypted in encrypted files
>
>
> Key: PDFBOX-3173
> URL: https://issues.apache.org/jira/browse/PDFBOX-3173
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto, Signing
>Affects Versions: 1.8.10, 1.8.11, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.11, 2.0.0
>
> Attachments: 045697.pdf, 050289.pdf, 070413.pdf, 346444.pdf,
> Sample_DocTimestamp.pdf
>
>
> Changes in PDFBOX-2801 and PDFBOX-2469 result in the signature dictionary not
> being decrypted in encrypted files. Because these aren't visible signatures,
> this is noticed only when looking at the signature dictionary in PDFDebugger.
> See also this thread in the dev mailing list:
> https://mail-archives.apache.org/mod_mbox/pdfbox-dev/201512.mbox/browser
> Example files:
> - PDFBOX-2711
> - 045697.pdf
> - 050289.pdf
> - 070413.pdf
> - 346444.pdf
> I hit that problem while wondering what to do about PDFBOX-2729, and wondered
> why the "too good to be true" solution of [~GGlad] worked at all, because his
> solution did encrypt the signature parts.
> I did not find anything in the "32000" spec that the signature dictionary is
> not to be encrypted.
> From [~msahyoun]:
> {quote}
> From ISO32000-2:
> Encryption applies to all strings and streams in the document's PDF file,
> with the following exceptions:
> The values for the ID entry in the trailer
> Any strings in an Encrypt dictionary
> Any strings that are inside streams such as content streams and compressed
> object streams, which themselves are encrypted
> Any hexadecimal strings representing the value of the Contents key in a
> Signature dictionary
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3173) Signature dictionary is not decrypted in encrypted files
[
https://issues.apache.org/jira/browse/PDFBOX-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069771#comment-15069771
]
Thomas Chojecki commented on PDFBOX-3173:
-
We should also handle document timestamps.
They use the signature dictionary as well, but has "DocTimeStamp" as value for
the Type.
See
http://www.etsi.org/deliver/etsi_ts/102700_102799/10277804/01.01.01_60/ts_10277804v010101p.pdf
Page 15, Chapter A.2, First table entry
> Signature dictionary is not decrypted in encrypted files
>
>
> Key: PDFBOX-3173
> URL: https://issues.apache.org/jira/browse/PDFBOX-3173
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto
>Affects Versions: 1.8.10, 1.8.11, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.11, 2.0.0
>
> Attachments: 045697.pdf, 050289.pdf, 070413.pdf
>
>
> Changes in PDFBOX-2801 and PDFBOX-2469 result in the signature dictionary not
> being decrypted in encrypted files. Because these aren't visible signatures,
> this is noticed only when looking at the signature dictionary in PDFDebugger.
> See also this thread in the dev mailing list:
> https://mail-archives.apache.org/mod_mbox/pdfbox-dev/201512.mbox/browser
> Example files:
> - PDFBOX-2711
> - 045697.pdf
> - 050289.pdf
> - 070413.pdf
> I hit that problem while wondering what to do about PDFBOX-2729, and wondered
> why the "too good to be true" solution of [~GGlad] worked at all, because his
> solution did encrypt the signature parts.
> I did not find anything in the "32000" spec that the signature dictionary is
> not to be encrypted.
> From [~msahyoun]:
> {quote}
> From ISO32000-2:
> Encryption applies to all strings and streams in the document's PDF file,
> with the following exceptions:
> The values for the ID entry in the trailer
> Any strings in an Encrypt dictionary
> Any strings that are inside streams such as content streams and compressed
> object streams, which themselves are encrypted
> Any hexadecimal strings representing the value of the Contents key in a
> Signature dictionary
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3173) Signature dictionary is not decrypted in encrypted files
[
https://issues.apache.org/jira/browse/PDFBOX-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-3173:
Attachment: Sample_DocTimestamp.pdf
> Signature dictionary is not decrypted in encrypted files
>
>
> Key: PDFBOX-3173
> URL: https://issues.apache.org/jira/browse/PDFBOX-3173
> Project: PDFBox
> Issue Type: Bug
> Components: Crypto, Signing
>Affects Versions: 1.8.10, 1.8.11, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: Tilman Hausherr
> Fix For: 1.8.11, 2.0.0
>
> Attachments: 045697.pdf, 050289.pdf, 070413.pdf,
> Sample_DocTimestamp.pdf
>
>
> Changes in PDFBOX-2801 and PDFBOX-2469 result in the signature dictionary not
> being decrypted in encrypted files. Because these aren't visible signatures,
> this is noticed only when looking at the signature dictionary in PDFDebugger.
> See also this thread in the dev mailing list:
> https://mail-archives.apache.org/mod_mbox/pdfbox-dev/201512.mbox/browser
> Example files:
> - PDFBOX-2711
> - 045697.pdf
> - 050289.pdf
> - 070413.pdf
> I hit that problem while wondering what to do about PDFBOX-2729, and wondered
> why the "too good to be true" solution of [~GGlad] worked at all, because his
> solution did encrypt the signature parts.
> I did not find anything in the "32000" spec that the signature dictionary is
> not to be encrypted.
> From [~msahyoun]:
> {quote}
> From ISO32000-2:
> Encryption applies to all strings and streams in the document's PDF file,
> with the following exceptions:
> The values for the ID entry in the trailer
> Any strings in an Encrypt dictionary
> Any strings that are inside streams such as content streams and compressed
> object streams, which themselves are encrypted
> Any hexadecimal strings representing the value of the Contents key in a
> Signature dictionary
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3169) SaveIncremental does not work without signature
[ https://issues.apache.org/jira/browse/PDFBOX-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-3169. - Resolution: Fixed > SaveIncremental does not work without signature > --- > > Key: PDFBOX-3169 > URL: https://issues.apache.org/jira/browse/PDFBOX-3169 > Project: PDFBox > Issue Type: Bug > Components: Writing >Affects Versions: 2.0.0 >Reporter: Thomas Chojecki >Assignee: Thomas Chojecki > Fix For: 2.0.0 > > Attachments: saveIncremental.patch > > > I know this feature is ongoing, but with the 2.0.0-RC builds the > saveIncremental (without signature) stop working at all. A > ByteArrayOutputStream is used in the COSWriter for output. This OutputStream > will only be handled in the case, when we write a signature. Otherwise the > whole content will be discarded. > As I wrote some time ago on the mailinglist, incremental update work in a > limited way. At the moment we use it for augmenting signatures and this works > with the old 1.8.x but not with trunk after the patch PDFBOX-1847 was applied. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3169) SaveIncremental does not work without signature
Thomas Chojecki created PDFBOX-3169: --- Summary: SaveIncremental does not work without signature Key: PDFBOX-3169 URL: https://issues.apache.org/jira/browse/PDFBOX-3169 Project: PDFBox Issue Type: Bug Components: Writing Affects Versions: 2.0.0 Reporter: Thomas Chojecki Assignee: Thomas Chojecki I know this feature is ongoing, but with the 2.0.0-RC builds the saveIncremental (without signature) stop working at all. A ByteArrayOutputStream is used in the COSWriter for output. This OutputStream will only be handled in the case, when we write a signature. Otherwise the whole content will be discarded. As I wrote some time ago on the mailinglist, incremental update work in a limited way. At the moment we use it for augmenting signatures and this works with the old 1.8.x but not with trunk after the patch PDFBOX-1847 was applied. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3169) SaveIncremental does not work without signature
[ https://issues.apache.org/jira/browse/PDFBOX-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-3169: Attachment: saveIncremental.patch The patch add an additional method, that handle the saveIncremental write for non-signature cases. It will copy the origin document and the incremental update into the given Outputstream. > SaveIncremental does not work without signature > --- > > Key: PDFBOX-3169 > URL: https://issues.apache.org/jira/browse/PDFBOX-3169 > Project: PDFBox > Issue Type: Bug > Components: Writing >Affects Versions: 2.0.0 >Reporter: Thomas Chojecki >Assignee: Thomas Chojecki > Attachments: saveIncremental.patch > > > I know this feature is ongoing, but with the 2.0.0-RC builds the > saveIncremental (without signature) stop working at all. A > ByteArrayOutputStream is used in the COSWriter for output. This OutputStream > will only be handled in the case, when we write a signature. Otherwise the > whole content will be discarded. > As I wrote some time ago on the mailinglist, incremental update work in a > limited way. At the moment we use it for augmenting signatures and this works > with the old 1.8.x but not with trunk after the patch PDFBOX-1847 was applied. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3169) SaveIncremental does not work without signature
[ https://issues.apache.org/jira/browse/PDFBOX-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060015#comment-15060015 ] Thomas Chojecki commented on PDFBOX-3169: - Yes. This will not solve the main need for easy incremental update of pdfs, but make it possible to do some minor incremental updates like augmenting signatures or something else that isn't complicated. After applying this patch at home, the saveIncremental method should work as it does in the 1.8 branch. > SaveIncremental does not work without signature > --- > > Key: PDFBOX-3169 > URL: https://issues.apache.org/jira/browse/PDFBOX-3169 > Project: PDFBox > Issue Type: Bug > Components: Writing >Affects Versions: 2.0.0 >Reporter: Thomas Chojecki >Assignee: Thomas Chojecki > Attachments: saveIncremental.patch > > > I know this feature is ongoing, but with the 2.0.0-RC builds the > saveIncremental (without signature) stop working at all. A > ByteArrayOutputStream is used in the COSWriter for output. This OutputStream > will only be handled in the case, when we write a signature. Otherwise the > whole content will be discarded. > As I wrote some time ago on the mailinglist, incremental update work in a > limited way. At the moment we use it for augmenting signatures and this works > with the old 1.8.x but not with trunk after the patch PDFBOX-1847 was applied. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2512) OutOfMemory while signing large documents
[ https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14245909#comment-14245909 ] Thomas Chojecki commented on PDFBOX-2512: - I will try to apply the fix next year to the trunk and take a look at PDFBOX-2515. The last test with the nonSeq parser and the large document linked in the issue description workes more or less and created a valid signature out of the box. But the size was more than twice of the original document OutOfMemory while signing large documents - Key: PDFBOX-2512 URL: https://issues.apache.org/jira/browse/PDFBOX-2512 Project: PDFBox Issue Type: Bug Components: Parsing, Signing Affects Versions: 1.8.7 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Fix For: 1.8.8 Attachments: keystore.p12 While working with large documents, we found some memory issues. 1. The method close() in the COSDocument, clones the objectpool and does not clean it properly. The cloning in getObjects() cause a OutOfMemory exception. 2.The COSWriter copy the whole pdf into the memory for signing and does not use BufferedInputStream for the FileInputStream which also has a big performance impact. (PDFBOX-1798) 3. The cloning of COSStreams cause a OutOfMemory exception I used the CreateSignature example with a about 150 MB big document from here: https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf Additionaly I add a RandomAccessFile to the PDDocument.load in the CreateSignature class. PDDocument doc = PDDocument.load(document,new RandomAccessFile(new File(d:\\temp.bin), rw)); (this prevent the OOM for the third case) The use of a BuffedInputStream in case two, will increase the signing speed from more than 5 minutes to less than 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PDFBOX-2512) OutOfMemory while signing large documents
[ https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-2512. - Resolution: Fixed Fix Version/s: 1.8.8 There is still one point open, but with the workaround mentioned in the comment, this issue is resolved. OutOfMemory while signing large documents - Key: PDFBOX-2512 URL: https://issues.apache.org/jira/browse/PDFBOX-2512 Project: PDFBox Issue Type: Bug Components: Parsing, Signing Affects Versions: 1.8.7 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Fix For: 1.8.8 Attachments: keystore.p12 While working with large documents, we found some memory issues. 1. The method close() in the COSDocument, clones the objectpool and does not clean it properly. The cloning in getObjects() cause a OutOfMemory exception. 2.The COSWriter copy the whole pdf into the memory for signing and does not use BufferedInputStream for the FileInputStream which also has a big performance impact. (PDFBOX-1798) 3. The cloning of COSStreams cause a OutOfMemory exception I used the CreateSignature example with a about 150 MB big document from here: https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf Additionaly I add a RandomAccessFile to the PDDocument.load in the CreateSignature class. PDDocument doc = PDDocument.load(document,new RandomAccessFile(new File(d:\\temp.bin), rw)); (this prevent the OOM for the third case) The use of a BuffedInputStream in case two, will increase the signing speed from more than 5 minutes to less than 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2512) OutOfMemory while signing large documents
[ https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237806#comment-14237806 ] Thomas Chojecki commented on PDFBOX-2512: - If we can port it, we should do it. There are only small changes, that improve the performance and solve the OOM problematic. OutOfMemory while signing large documents - Key: PDFBOX-2512 URL: https://issues.apache.org/jira/browse/PDFBOX-2512 Project: PDFBox Issue Type: Bug Components: Parsing, Signing Affects Versions: 1.8.7 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Fix For: 1.8.8 Attachments: keystore.p12 While working with large documents, we found some memory issues. 1. The method close() in the COSDocument, clones the objectpool and does not clean it properly. The cloning in getObjects() cause a OutOfMemory exception. 2.The COSWriter copy the whole pdf into the memory for signing and does not use BufferedInputStream for the FileInputStream which also has a big performance impact. (PDFBOX-1798) 3. The cloning of COSStreams cause a OutOfMemory exception I used the CreateSignature example with a about 150 MB big document from here: https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf Additionaly I add a RandomAccessFile to the PDDocument.load in the CreateSignature class. PDDocument doc = PDDocument.load(document,new RandomAccessFile(new File(d:\\temp.bin), rw)); (this prevent the OOM for the third case) The use of a BuffedInputStream in case two, will increase the signing speed from more than 5 minutes to less than 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2469) javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
[
https://issues.apache.org/jira/browse/PDFBOX-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222809#comment-14222809
]
Thomas Chojecki commented on PDFBOX-2469:
-
Ups, I simply forgot to write it to the OutputStream. My fault.
The case with the exception is, that the NonSeq parser already ignore it
silently and just log it. So both parser would act the same, if the new
exception block will be also logged and ignored. All I want to say is, that the
NonSeq parser run into the same error but handle it better. Failing the whole
decryption because one object can't be handled isn't good.
There are also cases where the NonSeq parser isn't working, So not every user
can just switch to it. Maybe you remember the signature discussion ;-) This
is one TODO I try to fix, but at the moment I haven't time to do it.
javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
-
Key: PDFBOX-2469
URL: https://issues.apache.org/jira/browse/PDFBOX-2469
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.7, 2.0.0
Reporter: Tim Allison
Assignee: Andreas Lehmkühler
Priority: Minor
Labels: AES128
Fix For: 1.8.8, 2.0.0
Attachments: FormI-9-English.pdf, PDFBOX-2469-regression.patch,
testPDF_acroForm.pdf
[~gagravarr] noticed that one of our old test files fails a Tika test now
with PDFBox 1.8.7 and Java 1.6.
I just tested the pure PDFBox app built with PDFBox 1.8.8-SNAPSHOT, and I'm
getting the same exception with Java 1.6 and Java 1.7.
Stacktrace:
{noformat}
ExtractText failed with the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not
properly padded
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at
org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:216)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Caused by: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:423)
at javax.crypto.Cipher.doFinal(Cipher.java:1708)
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:112)
... 12 more
{noformat}
java version 1.7.0_71
OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
java version 1.6.0_33
OpenJDK Runtime Environment (IcedTea6 1.13.5) (rhel-1.13.5.0.el6_6-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PDFBOX-2469) javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
[
https://issues.apache.org/jira/browse/PDFBOX-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222809#comment-14222809
]
Thomas Chojecki edited comment on PDFBOX-2469 at 11/24/14 9:18 AM:
---
Ups, I simply forgot to write it to the OutputStream. My fault.
I checked it twice now and I don't know why, but the NonSeq parser log
the exception that the stream can not be decrypted, but don't fail to finish
parsing. The legacy parser fails hard and stop parsing the rest of the document.
All I want to say is, that the NonSeq parser run into the same error but handle
it better. Failing the whole decryption because one object can't be handled
isn't good.
There are also cases where the NonSeq parser isn't working, So not every user
can just switch to it. Maybe you remember the signature discussion ;-) This
is one TODO I try to fix, but at the moment I haven't time to do it.
was (Author: tchojecki):
Ups, I simply forgot to write it to the OutputStream. My fault.
The case with the exception is, that the NonSeq parser already ignore it
silently and just log it. So both parser would act the same, if the new
exception block will be also logged and ignored. All I want to say is, that the
NonSeq parser run into the same error but handle it better. Failing the whole
decryption because one object can't be handled isn't good.
There are also cases where the NonSeq parser isn't working, So not every user
can just switch to it. Maybe you remember the signature discussion ;-) This
is one TODO I try to fix, but at the moment I haven't time to do it.
javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
-
Key: PDFBOX-2469
URL: https://issues.apache.org/jira/browse/PDFBOX-2469
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.7, 2.0.0
Reporter: Tim Allison
Assignee: Andreas Lehmkühler
Priority: Minor
Labels: AES128
Fix For: 1.8.8, 2.0.0
Attachments: FormI-9-English.pdf, PDFBOX-2469-regression.patch,
testPDF_acroForm.pdf
[~gagravarr] noticed that one of our old test files fails a Tika test now
with PDFBox 1.8.7 and Java 1.6.
I just tested the pure PDFBox app built with PDFBox 1.8.8-SNAPSHOT, and I'm
getting the same exception with Java 1.6 and Java 1.7.
Stacktrace:
{noformat}
ExtractText failed with the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not
properly padded
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at
org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:216)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Caused by: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:423)
at javax.crypto.Cipher.doFinal(Cipher.java:1708)
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:112)
... 12 more
{noformat}
java version 1.7.0_71
OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
java version 1.6.0_33
OpenJDK Runtime Environment (IcedTea6 1.13.5) (rhel-1.13.5.0.el6_6-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2469) javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
[
https://issues.apache.org/jira/browse/PDFBOX-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-2469:
Attachment: PDFBOX-2469-regression.patch
This patch would fix the regression.
I moved the doFinal outside of the loop. It won't change the behavior, but it
looks more clear and InputStream#available isn't needed any more, which can
cause problems with some streams (see the JavaDoc)
The two new exceptions does not throw the WrappedIOException anymore.
javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
-
Key: PDFBOX-2469
URL: https://issues.apache.org/jira/browse/PDFBOX-2469
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.7, 2.0.0
Reporter: Tim Allison
Assignee: Andreas Lehmkühler
Priority: Minor
Labels: AES128
Fix For: 1.8.8, 2.0.0
Attachments: PDFBOX-2469-regression.patch, testPDF_acroForm.pdf
[~gagravarr] noticed that one of our old test files fails a Tika test now
with PDFBox 1.8.7 and Java 1.6.
I just tested the pure PDFBox app built with PDFBox 1.8.8-SNAPSHOT, and I'm
getting the same exception with Java 1.6 and Java 1.7.
Stacktrace:
{noformat}
ExtractText failed with the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not
properly padded
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at
org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:216)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Caused by: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:423)
at javax.crypto.Cipher.doFinal(Cipher.java:1708)
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:112)
... 12 more
{noformat}
java version 1.7.0_71
OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
java version 1.6.0_33
OpenJDK Runtime Environment (IcedTea6 1.13.5) (rhel-1.13.5.0.el6_6-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2469) javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
[
https://issues.apache.org/jira/browse/PDFBOX-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221006#comment-14221006
]
Thomas Chojecki commented on PDFBOX-2469:
-
I've attached it to the issue PDFBOX-2469-regression.patch
javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
-
Key: PDFBOX-2469
URL: https://issues.apache.org/jira/browse/PDFBOX-2469
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.7, 2.0.0
Reporter: Tim Allison
Assignee: Andreas Lehmkühler
Priority: Minor
Labels: AES128
Fix For: 1.8.8, 2.0.0
Attachments: PDFBOX-2469-regression.patch, testPDF_acroForm.pdf
[~gagravarr] noticed that one of our old test files fails a Tika test now
with PDFBox 1.8.7 and Java 1.6.
I just tested the pure PDFBox app built with PDFBox 1.8.8-SNAPSHOT, and I'm
getting the same exception with Java 1.6 and Java 1.7.
Stacktrace:
{noformat}
ExtractText failed with the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not
properly padded
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at
org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:216)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Caused by: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:423)
at javax.crypto.Cipher.doFinal(Cipher.java:1708)
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:112)
... 12 more
{noformat}
java version 1.7.0_71
OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
java version 1.6.0_33
OpenJDK Runtime Environment (IcedTea6 1.13.5) (rhel-1.13.5.0.el6_6-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2469) javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
[
https://issues.apache.org/jira/browse/PDFBOX-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-2469:
Attachment: FormI-9-English.pdf
javax.crypto.BadPaddingException in PDFBox 1.8.8-SNAPSHOT
-
Key: PDFBOX-2469
URL: https://issues.apache.org/jira/browse/PDFBOX-2469
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.7, 2.0.0
Reporter: Tim Allison
Assignee: Andreas Lehmkühler
Priority: Minor
Labels: AES128
Fix For: 1.8.8, 2.0.0
Attachments: FormI-9-English.pdf, PDFBOX-2469-regression.patch,
testPDF_acroForm.pdf
[~gagravarr] noticed that one of our old test files fails a Tika test now
with PDFBox 1.8.7 and Java 1.6.
I just tested the pure PDFBox app built with PDFBox 1.8.8-SNAPSHOT, and I'm
getting the same exception with Java 1.6 and Java 1.7.
Stacktrace:
{noformat}
ExtractText failed with the following exception:
java.io.IOException: javax.crypto.BadPaddingException: Given final block not
properly padded
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:118)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:236)
at javax.crypto.CipherInputStream.read(CipherInputStream.java:212)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:316)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:421)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decrypt(SecurityHandler.java:390)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptObject(SecurityHandler.java:365)
at
org.apache.pdfbox.pdmodel.encryption.SecurityHandler.proceedDecryption(SecurityHandler.java:196)
at
org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:158)
at
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1598)
at org.apache.pdfbox.ExtractText.startExtraction(ExtractText.java:216)
at org.apache.pdfbox.ExtractText.main(ExtractText.java:85)
at org.apache.pdfbox.PDFBox.main(PDFBox.java:58)
Caused by: javax.crypto.BadPaddingException: Given final block not properly
padded
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:423)
at javax.crypto.Cipher.doFinal(Cipher.java:1708)
at
javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:112)
... 12 more
{noformat}
java version 1.7.0_71
OpenJDK Runtime Environment (rhel-2.5.3.1.el6-x86_64 u71-b14)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
and
java version 1.6.0_33
OpenJDK Runtime Environment (IcedTea6 1.13.5) (rhel-1.13.5.0.el6_6-x86_64)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PDFBOX-2512) OutOfMemory while signing large documents
Thomas Chojecki created PDFBOX-2512: --- Summary: OutOfMemory while signing large documents Key: PDFBOX-2512 URL: https://issues.apache.org/jira/browse/PDFBOX-2512 Project: PDFBox Issue Type: Bug Components: Parsing, Signing Affects Versions: 1.8.7 Reporter: Thomas Chojecki Assignee: Thomas Chojecki While working with large documents, we found some memory issues. 1. The method close() in the COSDocument, clones the objectpool and does not clean it properly. The cloning in getObjects() cause a OutOfMemory exception. 2.The COSWriter copy the whole pdf into the memory for signing and does not use BufferedInputStream for the FileInputStream which also has a big performance impact. (PDFBOX-1798) 3. The cloning of COSStreams cause a OutOfMemory exception I used the CreateSignature example with a about 150 MB big document from here: https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf Additionaly I add a RandomAccessFile to the PDDocument.load in the CreateSignature class. PDDocument doc = PDDocument.load(document,new RandomAccessFile(new File(d:\\temp.bin), rw)); (this prevent the OOM for the third case) The use of a BuffedInputStream in case two, will increase the signing speed from more than 5 minutes to less than 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-1625) java.lang.IndexOutOfBoundsException at writing PDF file
[ https://issues.apache.org/jira/browse/PDFBOX-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219691#comment-14219691 ] Thomas Chojecki commented on PDFBOX-1625: - I have some problems with the clone patch :-( Trying to resolve some OOM and performance issues for PDFBOX-2512 and I'm stuck with the changes from the clone.patch The line return ((RandomAccessBuffer)file).clone(); cause a OOM for documents with many / large streams. I my case the scratchfile (if I use a RandomAccessFile) grows to about 140MB. So the only fix for the PDFBOX-2512 issue is to use a RandomAccessFile. Undoing the clone patch cause four tests to fail. java.lang.IndexOutOfBoundsException at writing PDF file --- Key: PDFBOX-1625 URL: https://issues.apache.org/jira/browse/PDFBOX-1625 Project: PDFBox Issue Type: Bug Components: Writing Affects Versions: 1.8.2 Environment: Linux, Java 7u21 Reporter: Jens Kapitza Assignee: Guillaume Bailleul Priority: Minor Fix For: 1.8.4, 2.0.0 Attachments: clone.patch, pdftool.zip I got this error: i will just recreate a document with pages 1-6. Exception in thread main java.io.IOException: org.apache.pdfbox.exceptions.COSVisitorException: java.lang.IndexOutOfBoundsException: Index: 115, Size: 0 at de.back2heaven.pdf.model.TargetDocumuent.save(TargetDocumuent.java:56) at de.back2heaven.pdf.model.Document.prozess(Document.java:76) at de.back2heaven.pdf.model.Document.main(Document.java:56) Caused by: org.apache.pdfbox.exceptions.COSVisitorException: java.lang.IndexOutOfBoundsException: Index: 115, Size: 0 at org.apache.pdfbox.pdfwriter.COSWriter.visitFromStream(COSWriter.java:1354) at org.apache.pdfbox.cos.COSStream.accept(COSStream.java:217) at org.apache.pdfbox.cos.COSObject.accept(COSObject.java:206) at org.apache.pdfbox.pdfwriter.COSWriter.doWriteObject(COSWriter.java:525) at org.apache.pdfbox.pdfwriter.COSWriter.doWriteBody(COSWriter.java:435) at org.apache.pdfbox.pdfwriter.COSWriter.visitFromDocument(COSWriter.java:1122) at org.apache.pdfbox.cos.COSDocument.accept(COSDocument.java:552) at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1501) at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:1324) at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:1305) at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:1292) at de.back2heaven.pdf.model.TargetDocumuent.save(TargetDocumuent.java:54) ... 2 more Caused by: java.lang.IndexOutOfBoundsException: Index: 115, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:604) at java.util.ArrayList.get(ArrayList.java:382) at org.apache.pdfbox.io.RandomAccessBuffer.seek(RandomAccessBuffer.java:84) at org.apache.pdfbox.io.RandomAccessFileInputStream.read(RandomAccessFileInputStream.java:96) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at org.apache.pdfbox.pdfwriter.COSWriter.visitFromStream(COSWriter.java:1337) ... 13 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PDFBOX-2512) OutOfMemory while signing large documents
[ https://issues.apache.org/jira/browse/PDFBOX-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-2512: Attachment: keystore.p12 I've add a sample keystore For testing just run the class CreateSignature with the arguments like: D:\keystore.p12 123456 D:\Sonstiges\reichelt_01-2015_DE_B_HQ.pdf For getting the OOM in the 3'rd case, the line PDDocument doc = PDDocument.load(document, randomAccessFile); need to be changed to PDDocument doc = PDDocument.load(document); OutOfMemory while signing large documents - Key: PDFBOX-2512 URL: https://issues.apache.org/jira/browse/PDFBOX-2512 Project: PDFBox Issue Type: Bug Components: Parsing, Signing Affects Versions: 1.8.7 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Attachments: keystore.p12 While working with large documents, we found some memory issues. 1. The method close() in the COSDocument, clones the objectpool and does not clean it properly. The cloning in getObjects() cause a OutOfMemory exception. 2.The COSWriter copy the whole pdf into the memory for signing and does not use BufferedInputStream for the FileInputStream which also has a big performance impact. (PDFBOX-1798) 3. The cloning of COSStreams cause a OutOfMemory exception I used the CreateSignature example with a about 150 MB big document from here: https://cdn-reichelt.de/bilder/downloads/reichelt_01-2015_DE_B_HQ.pdf Additionaly I add a RandomAccessFile to the PDDocument.load in the CreateSignature class. PDDocument doc = PDDocument.load(document,new RandomAccessFile(new File(d:\\temp.bin), rw)); (this prevent the OOM for the third case) The use of a BuffedInputStream in case two, will increase the signing speed from more than 5 minutes to less than 1 minute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PDFBOX-2250) Improve XRef self healing mechanism
[ https://issues.apache.org/jira/browse/PDFBOX-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093152#comment-14093152 ] Thomas Chojecki commented on PDFBOX-2250: - [~lehmi] All fixes and improvements are targeting the non-sequential parser and I won't port those changes to the old parser. The old parser already has this feature or similar one as I remember. This was needed as fix for a third party lib that creates documents that have a miss matched offset by 2 or 3 bytes. You can find it in the PDFParser class line 923 (resolveConflicts). https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdfparser/PDFParser.java#L923 I don't have read the whole coversation, but you wrote something of 200 bytes self healing range. This can cause problems with pdfs that are broken and include pdf documents as file attachment. The flatdecode algorithm sometimes does not compress each block, so it will leave some plaintext pdf blocks whick can contain parts like endstream or endobj. In this case it can happen that the self healing algorithm runs into such an uncompressed block and fail reading the object. I hope you understand what I mean :-) PS: some offtopic things. I think the signature implementation only work with the old parser. So maybe someone can post this info on the website if the default parser implementation change. Improve XRef self healing mechanism --- Key: PDFBOX-2250 URL: https://issues.apache.org/jira/browse/PDFBOX-2250 Project: PDFBox Issue Type: Improvement Components: Parsing Affects Versions: 1.8.6, 1.8.7, 2.0.0 Reporter: Andreas Lehmkühler Assignee: Andreas Lehmkühler PDFBOX-1769 introduced a self healing mechanism to repair corrupt XRef offsets. But that one was just a starter and there remain a lot of issues to be solved. I'm planing to solve at least some of them. All fixes and improvements are targeting the non-sequential parser and I won't port those changes to the old parser. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (PDFBOX-45) Support incremental save
[ https://issues.apache.org/jira/browse/PDFBOX-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki reopened PDFBOX-45: --- The saveIncremental(...) method was a first try to do this, but is unfortunately only work for signatures. The recursive writer make it hard to implement this feature, because he starts always with the catalog and if for example a new page was added, all elements on the way to this new page need to be written again. So we need a extra writer for this task that does not work recursive and instead use maybe a set or a map for objects that need to be written. Or the writer should iterate always over all objects and only write new ones. I would prefer a new writer, because it seams to be cleaner to write objects from a collection instead of trying to iterate through all objects and finding new ones and maybe end up in loops. So it's a bigger task for the version 2.0 Support incremental save Key: PDFBOX-45 URL: https://issues.apache.org/jira/browse/PDFBOX-45 Project: PDFBox Issue Type: New Feature Components: Writing [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552835aid=1157431 Originally submitted by purplish_cat on 2005-03-05 12:28. After opening a PDF file and changing objects out of it, allow to save the changes incrementally to the same file instead of creating a completely new file. [comment on SourceForge] Originally sent by benlitchfield. Logged In: YES user_id=601708 See forum thread at https://sourceforge.net/forum/message.php?msg_id=3032112 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-2001) Digital Signature information
[ https://issues.apache.org/jira/browse/PDFBOX-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13947753#comment-13947753 ] Thomas Chojecki commented on PDFBOX-2001: - There is a problem parsing the field dictionary. It should contain two entries but if I get the first entry, I will get the field dictionary object. It is some kind of parsing problem. The document catalog looks really weird, it contains only direct objects up to the felds. Also it has a second signature encapsulate inside the perms dictionary. Digital Signature information - Key: PDFBOX-2001 URL: https://issues.apache.org/jira/browse/PDFBOX-2001 Project: PDFBox Issue Type: Bug Affects Versions: 1.8.3 Reporter: Nicolas Kaczmarski Attachments: D.1_signiert.pdf We have a signed PDF but signature is described without key Sig. As you can see in the standard PDF 32000-1:2008 - Table 252 - Entries in a signature dictionary, this key is optional : (Optional) The type of PDF object that this dictionary describes; if present, shall be Sig for a signature dictionary. But PDFBox seems to limit its research of signature only if this key Sig is present. What is your position about that? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1330) Generic changes
[ https://issues.apache.org/jira/browse/PDFBOX-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896280#comment-13896280 ] Thomas Chojecki commented on PDFBOX-1330: - This changes will be done in the pdfbox 2.0.0 Maybe we can use some of the diffs if there aren't to many changes done in the past Generic changes --- Key: PDFBOX-1330 URL: https://issues.apache.org/jira/browse/PDFBOX-1330 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 1.8.0 Reporter: Jens Kapitza Attachments: PDFTextStripperByArea.java.diff, PDPageNode.java.diff, PDPageNode.java.diff, TextNormalize.diff, TextPosition.diff Original Estimate: 5m Remaining Estimate: 5m -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-13) Add ability to digitally sign a PDF
[ https://issues.apache.org/jira/browse/PDFBOX-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-13. --- Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Thomas Chojecki This is already resolved with PDFBOX-912.So we can close it. Add ability to digitally sign a PDF --- Key: PDFBOX-13 URL: https://issues.apache.org/jira/browse/PDFBOX-13 Project: PDFBox Issue Type: New Feature Components: Signing Assignee: Thomas Chojecki Fix For: 1.8.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552835aid=1000109 Originally submitted by benlitchfield on 2004-07-29 06:27. Implementation Notes: What about the info on this site: http://www.codeproject.com/useritems/PdfDigiPad.asp Adobe PDF Public-Key Digital Signature and Encryption Specification http://partners.adobe.com/asn/developer/pdfs/tn/ppk_pd fspec.pdf Adobe Acrobat Digital Signature API Reference http://partners.adobe.com/asn/acrobat/docs/digsig.pdf http://www.mail-archive.com/itext- questi...@lists.sourceforge.net/msg11084.html http://groups.google.de/groups? q=sign+openssl+group:comp.text.pdfhl=delr=lang_de|l ang_enie=UTF- 8group=comp.text.pdfselm=f55510dc.0403111256.f0a6 513%40posting.google.comrnum=1 [comment on SourceForge] Originally sent by notessensei. Logged In: YES user_id=675521 I second the request [comment on SourceForge] Originally sent by benlitchfield. Logged In: YES user_id=601708 The org.pdfbox.pdmodel.interactive.digitalsignature package has been created but needs to be implemented. Ben [comment on SourceForge] Originally sent by benlitchfield. Logged In: YES user_id=601708 java example of signing a pdf using an x509 certificate from a file or a X506Certificate instance -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-275) add digital signature support
[ https://issues.apache.org/jira/browse/PDFBOX-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-275. Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Thomas Chojecki This is already resolved with PDFBOX-912. So we can close it. add digital signature support - Key: PDFBOX-275 URL: https://issues.apache.org/jira/browse/PDFBOX-275 Project: PDFBox Issue Type: New Feature Components: Signing Assignee: Thomas Chojecki Priority: Minor Fix For: 1.6.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552835aid=1719860 Originally submitted by ulifu on 2007-05-16 01:43. please add support to include a digital signature in a PDF file -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (PDFBOX-13) Add ability to digitally sign a PDF
[ https://issues.apache.org/jira/browse/PDFBOX-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki closed PDFBOX-13. - Add ability to digitally sign a PDF --- Key: PDFBOX-13 URL: https://issues.apache.org/jira/browse/PDFBOX-13 Project: PDFBox Issue Type: New Feature Components: Signing Assignee: Thomas Chojecki Fix For: 1.8.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552835aid=1000109 Originally submitted by benlitchfield on 2004-07-29 06:27. Implementation Notes: What about the info on this site: http://www.codeproject.com/useritems/PdfDigiPad.asp Adobe PDF Public-Key Digital Signature and Encryption Specification http://partners.adobe.com/asn/developer/pdfs/tn/ppk_pd fspec.pdf Adobe Acrobat Digital Signature API Reference http://partners.adobe.com/asn/acrobat/docs/digsig.pdf http://www.mail-archive.com/itext- questi...@lists.sourceforge.net/msg11084.html http://groups.google.de/groups? q=sign+openssl+group:comp.text.pdfhl=delr=lang_de|l ang_enie=UTF- 8group=comp.text.pdfselm=f55510dc.0403111256.f0a6 513%40posting.google.comrnum=1 [comment on SourceForge] Originally sent by notessensei. Logged In: YES user_id=675521 I second the request [comment on SourceForge] Originally sent by benlitchfield. Logged In: YES user_id=601708 The org.pdfbox.pdmodel.interactive.digitalsignature package has been created but needs to be implemented. Ben [comment on SourceForge] Originally sent by benlitchfield. Logged In: YES user_id=601708 java example of signing a pdf using an x509 certificate from a file or a X506Certificate instance -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (PDFBOX-236) PDF parse signature version
[ https://issues.apache.org/jira/browse/PDFBOX-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki closed PDFBOX-236. -- PDF parse signature version --- Key: PDFBOX-236 URL: https://issues.apache.org/jira/browse/PDFBOX-236 Project: PDFBox Issue Type: Bug Components: Signing Assignee: Thomas Chojecki Priority: Minor Fix For: 1.6.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552833aid=1636977 Originally submitted by dlapdfuser on 2007-01-16 09:49. When parsing a pdf that has been signed multiple times, the field values parsed are the ones from the first signing. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-236) PDF parse signature version
[ https://issues.apache.org/jira/browse/PDFBOX-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-236. Resolution: Fixed Fix Version/s: 1.6.0 Assignee: Thomas Chojecki PDDocument provide the method getSignatureDictionaries(), which return all signatures. The signature search is based on the AcroForm Fields. So the signature filed from multiple signed documents will be shown correct. If not, maybe the document is broken. I will close this one, because I is really old and there is no document attached with which i can reproduce your problem. PDF parse signature version --- Key: PDFBOX-236 URL: https://issues.apache.org/jira/browse/PDFBOX-236 Project: PDFBox Issue Type: Bug Components: Signing Assignee: Thomas Chojecki Priority: Minor Fix For: 1.6.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552833aid=1636977 Originally submitted by dlapdfuser on 2007-01-16 09:49. When parsing a pdf that has been signed multiple times, the field values parsed are the ones from the first signing. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (PDFBOX-273) PDDocument.save should not close stream
[ https://issues.apache.org/jira/browse/PDFBOX-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki closed PDFBOX-273. -- PDDocument.save should not close stream --- Key: PDFBOX-273 URL: https://issues.apache.org/jira/browse/PDFBOX-273 Project: PDFBox Issue Type: Bug Components: Writing Assignee: Thomas Chojecki Priority: Minor Fix For: 1.8.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552832aid=1714574 Originally submitted by wasabii on 2007-05-07 13:13. Calling PDDocument.save should not close the underlying stream. It is not appropiate in this location and causes double-close issues when the calling code assumes responsibility for the stream. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-273) PDDocument.save should not close stream
[ https://issues.apache.org/jira/browse/PDFBOX-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-273. Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Thomas Chojecki A look at the PDDocument save() Method shows that at the moment only the COSWriter will be closed. Other resources will be closed with the close() method. So I think this is already solved. As I can not find out in which version this change was made, I tag the fix version as 1.8.0. PDDocument.save should not close stream --- Key: PDFBOX-273 URL: https://issues.apache.org/jira/browse/PDFBOX-273 Project: PDFBox Issue Type: Bug Components: Writing Assignee: Thomas Chojecki Priority: Minor Fix For: 1.8.0 [imported from SourceForge] http://sourceforge.net/tracker/index.php?group_id=78314atid=552832aid=1714574 Originally submitted by wasabii on 2007-05-07 13:13. Calling PDDocument.save should not close the underlying stream. It is not appropiate in this location and causes double-close issues when the calling code assumes responsibility for the stream. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-423) Can't detect if the PDF ( ver 1.7 ) is encrypted or not.
[ https://issues.apache.org/jira/browse/PDFBOX-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-423. Resolution: Fixed Fix Version/s: 1.8.0 Assignee: Thomas Chojecki Seems to be already solved. Parsing incremental updated documents should work at least with the version 1.4 Can't detect if the PDF ( ver 1.7 ) is encrypted or not. Key: PDFBOX-423 URL: https://issues.apache.org/jira/browse/PDFBOX-423 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 0.8.0-incubator Environment: Windows Vista Reporter: Takashi Komatsubara Assignee: Thomas Chojecki Fix For: 1.8.0 Attachments: pass17.pdf The latest PDFBox can't detect if the PDF ( Ver 1.7 ) created by Acrobat 9 is encrypted or not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (PDFBOX-423) Can't detect if the PDF ( ver 1.7 ) is encrypted or not.
[ https://issues.apache.org/jira/browse/PDFBOX-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki closed PDFBOX-423. -- Can't detect if the PDF ( ver 1.7 ) is encrypted or not. Key: PDFBOX-423 URL: https://issues.apache.org/jira/browse/PDFBOX-423 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 0.8.0-incubator Environment: Windows Vista Reporter: Takashi Komatsubara Assignee: Thomas Chojecki Fix For: 1.8.0 Attachments: pass17.pdf The latest PDFBox can't detect if the PDF ( Ver 1.7 ) created by Acrobat 9 is encrypted or not. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1780) previous revision is damaged after signing
[ https://issues.apache.org/jira/browse/PDFBOX-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880871#comment-13880871 ] Thomas Chojecki commented on PDFBOX-1780: - Never ending story. If I revert locally the COSWriter change, some documents can't be signed twice again and some can. I can't find the root cause for this behaviour. I'm testing with the 1.8.3 release right now and got also the problem that at least one document can't be parsed properly after creating a second signature. Adobe has no problem reading the document and the signatures. previous revision is damaged after signing -- Key: PDFBOX-1780 URL: https://issues.apache.org/jira/browse/PDFBOX-1780 Project: PDFBox Issue Type: Bug Components: Parsing, Signing, Writing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Priority: Critical Fix For: 1.8.3, 2.0.0 Attachments: fixed.jpg, fixed.patch, original-signed -[FIXED].pdf, original-signed [DAMAGED].pdf, original-signed [ORIGINAL].pdf Ihave PDF file which was signed by some other application. When I try to sign it with PDFbox, previous revision is damaged. I have discussion at stackoverflow, with Michael Klink. http://stackoverflow.com/questions/19903884/pdf-document-is-modified-by-another-revision/19905271?noredirect=1#19905271 when we see some changes merely was structural. Some changes was just rounding problem - PDFBOX-1778. When I test, problem of damaged signature was caused from structural change [when there must be direct reference, there was indirect reference and etc..] So we solve that problem. I will upload damaged PDF document, fixed pdf, and the patch too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879792#comment-13879792 ] Thomas Chojecki commented on PDFBOX-1822: - We also have hybrid xref documents out there. Hope this will not break the existing function. I will test it today. Changing the parser to non-sequential would indeed solve all signing problems. :-) There will be no signatures, because the incremental update does not work with the non seq parser (testet it a while ago). SCNR Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Fix For: 1.8.4, 2.0.0 Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf, unsigned_signed_fix.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879792#comment-13879792 ] Thomas Chojecki edited comment on PDFBOX-1822 at 1/23/14 10:03 AM: --- We also have hybrid xref documents out there. Hope this will not break the existing function. I will test it today. Changing the parser to non-sequential would indeed solve all signing problems. :-) There will be no signatures, because the incremental update does not work with the non seq parser (testet it a while ago). SCNR EDIT: OK the NonSeq works for signatures *stunned*. Doesn't mentioned that this was fixed. The SVN is actual down, so I can't apply your patch at the moment. was (Author: tchojecki): We also have hybrid xref documents out there. Hope this will not break the existing function. I will test it today. Changing the parser to non-sequential would indeed solve all signing problems. :-) There will be no signatures, because the incremental update does not work with the non seq parser (testet it a while ago). SCNR Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Fix For: 1.8.4, 2.0.0 Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf, unsigned_signed_fix.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879792#comment-13879792 ] Thomas Chojecki edited comment on PDFBOX-1822 at 1/23/14 10:38 AM: --- We also have hybrid xref documents out there. Hope this will not break the existing function. I will test it today. Changing the parser to non-sequential would indeed solve all signing problems. :-) There will be no signatures, because the incremental update does not work with the non seq parser (testet it a while ago). SCNR EDIT: OK the NonSeq works for signatures *stunned*. Doesn't mentioned that this was fixed. Hybrid XRef documents still working. Thx for the patch was (Author: tchojecki): We also have hybrid xref documents out there. Hope this will not break the existing function. I will test it today. Changing the parser to non-sequential would indeed solve all signing problems. :-) There will be no signatures, because the incremental update does not work with the non seq parser (testet it a while ago). SCNR EDIT: OK the NonSeq works for signatures *stunned*. Doesn't mentioned that this was fixed. The SVN is actual down, so I can't apply your patch at the moment. Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Fix For: 1.8.4, 2.0.0 Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf, unsigned_signed_fix.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PDFBOX-1862) Incomplete signature creation (regression in 1.8.3 with PDFBOX-1780)
Thomas Chojecki created PDFBOX-1862: --- Summary: Incomplete signature creation (regression in 1.8.3 with PDFBOX-1780) Key: PDFBOX-1862 URL: https://issues.apache.org/jira/browse/PDFBOX-1862 Project: PDFBox Issue Type: Bug Components: Signing, Writing Affects Versions: 1.8.3 Reporter: Thomas Chojecki I got a document, which do not look special but after the PDFBOX-1780 patch, signing breaks and only a small footprint was written into the document. The changes made with the patch PDFBOX-1780 in the COSWriter, cause this problem for me. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PDFBOX-1862) Incomplete signature creation (regression in 1.8.3 with PDFBOX-1780)
[ https://issues.apache.org/jira/browse/PDFBOX-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1862: Attachment: b_Test-1x-signed_signed_broken.pdf b_Test-1x-signed_signed.pdf b_Test-1x-signed.pdf b_Test-1x-signed (original document) b_Test-1x-signed_signed (made with a version previous 1.8.3) b_Test-1x-signed_signed (made with the 1.8.3) Incomplete signature creation (regression in 1.8.3 with PDFBOX-1780) Key: PDFBOX-1862 URL: https://issues.apache.org/jira/browse/PDFBOX-1862 Project: PDFBox Issue Type: Bug Components: Signing, Writing Affects Versions: 1.8.3 Reporter: Thomas Chojecki Attachments: b_Test-1x-signed.pdf, b_Test-1x-signed_signed.pdf, b_Test-1x-signed_signed_broken.pdf I got a document, which do not look special but after the PDFBOX-1780 patch, signing breaks and only a small footprint was written into the document. The changes made with the patch PDFBOX-1780 in the COSWriter, cause this problem for me. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1780) previous revision is damaged after signing
[ https://issues.apache.org/jira/browse/PDFBOX-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879934#comment-13879934 ] Thomas Chojecki commented on PDFBOX-1780: - The patch contains two parts. One is the setDirect which fix the PDFBOX-1314 issue. So the parser know which document was written directly and save this behaviour. This part fix also the signature problematic for at least my problematic documents with multiple signatures over different pages. The second is the COSWriter patch. What does this patch do? This line broke the signature creation for at least one document see PDFBOX-1862. Do we need this? Can we maybe revert it? previous revision is damaged after signing -- Key: PDFBOX-1780 URL: https://issues.apache.org/jira/browse/PDFBOX-1780 Project: PDFBox Issue Type: Bug Components: Parsing, Signing, Writing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Priority: Critical Fix For: 1.8.3, 2.0.0 Attachments: fixed.jpg, fixed.patch, original-signed -[FIXED].pdf, original-signed [DAMAGED].pdf, original-signed [ORIGINAL].pdf Ihave PDF file which was signed by some other application. When I try to sign it with PDFbox, previous revision is damaged. I have discussion at stackoverflow, with Michael Klink. http://stackoverflow.com/questions/19903884/pdf-document-is-modified-by-another-revision/19905271?noredirect=1#19905271 when we see some changes merely was structural. Some changes was just rounding problem - PDFBOX-1778. When I test, problem of damaged signature was caused from structural change [when there must be direct reference, there was indirect reference and etc..] So we solve that problem. I will upload damaged PDF document, fixed pdf, and the patch too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1780) previous revision is damaged after signing
[ https://issues.apache.org/jira/browse/PDFBOX-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879965#comment-13879965 ] Thomas Chojecki commented on PDFBOX-1780: - Thx for the quick response and coming revert. previous revision is damaged after signing -- Key: PDFBOX-1780 URL: https://issues.apache.org/jira/browse/PDFBOX-1780 Project: PDFBox Issue Type: Bug Components: Parsing, Signing, Writing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Priority: Critical Fix For: 1.8.3, 2.0.0 Attachments: fixed.jpg, fixed.patch, original-signed -[FIXED].pdf, original-signed [DAMAGED].pdf, original-signed [ORIGINAL].pdf Ihave PDF file which was signed by some other application. When I try to sign it with PDFbox, previous revision is damaged. I have discussion at stackoverflow, with Michael Klink. http://stackoverflow.com/questions/19903884/pdf-document-is-modified-by-another-revision/19905271?noredirect=1#19905271 when we see some changes merely was structural. Some changes was just rounding problem - PDFBOX-1778. When I test, problem of damaged signature was caused from structural change [when there must be direct reference, there was indirect reference and etc..] So we solve that problem. I will upload damaged PDF document, fixed pdf, and the patch too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1822: Attachment: SignatureFileSet-PDFBOX-1.8.2_TO_1.8.4-SNAPSHOT_SEQ_AND_NONSEQ.zip I have attached a zip with a set of files. The files represent the signing results between the pdfbox versions 1.8.2 and 1.8.4-SNAPSHOT and two examples done with NonSeq parser. The document I used for the signatures (ToBeSigned.pdf) is valid, already signed and use a XRefStream. *Result:* NonSeq does not work at all. It copy the whole document instead of only writing affected objects. 1.8.2 - has problem attaching a second signature on this kind of document. *does not work* 1.8.3 - solves this problem. *work* 1.8.4-SNAPSHOT - is the latest 1.8.x branch without the patch from this Issue. *work* 1.8.4-SNAPSHOT_WITH_PDFBOX-1822_PATCH - is the version with the patch from this issue. *does not work* Instead of an XRefStream a XRefTable was wrote. Make no sense in this case. The biggest problem is, all JUnit tests went well. I checked each document with the latest Adobe Reader to find the problems. Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Fix For: 1.8.4, 2.0.0 Attachments: SignatureFileSet-PDFBOX-1.8.2_TO_1.8.4-SNAPSHOT_SEQ_AND_NONSEQ.zip, araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf, unsigned_signed_fix.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-1857) Attachment damages singature
[ https://issues.apache.org/jira/browse/PDFBOX-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1857. - Resolution: Duplicate Assignee: Thomas Chojecki You got two problems here. 1.) Attaching content after signing. 2.) Problem with the id management. 1.) not solvable right now (see PDFBOX-1837). We would need to change the object storing engine and rewrite the writer. So if you want to attach content, you should do it before the first sign, or remove the signature before attaching content and then you can sign again. 2.) I looked in the specification PDF3200-1:2008 at the chapter 14.4 and can confirm the solution that was mentioned on stackoverflow. nonetheless i close it as duplicated, because the main problem is the broken signature. Attachment damages singature Key: PDFBOX-1857 URL: https://issues.apache.org/jira/browse/PDFBOX-1857 Project: PDFBox Issue Type: Bug Components: Parsing, PDFReader, Signing, Utilities, Writing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: jack Assignee: Thomas Chojecki Priority: Blocker Attachments: attach.txt, original.pdf, original[signed].pdf, original[with-attachment].pdf, original[with-attachment][signed].pdf I have PDF document. 1) Adobe reader reads document well. 2) I sign document (using pdfbox-examples) and everything is well 3) Then I try to attach file to original PDF (Code is written in the pdfbox web page - in the cookBook). 4) Adobe reader reads attached document well. everything is well. 5) Now I have document with attachment. 6) I try to sign that document (I mean document with attachment). And I have 2 problem: First: when I open document, Adobe reader tells me that signature byte range is invalid. Second: when I try to close document (I mean to close adobe reader), Adobe reader tells me that: Do you want to save changes to original[with-attachment][signed] before closing? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1857) Attachment damages singature
[ https://issues.apache.org/jira/browse/PDFBOX-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878492#comment-13878492 ] Thomas Chojecki commented on PDFBOX-1857: - Sorry, I misinterpreted your point 2 and 3 in the comment. I thought you try to attach a file to a signed document. So this is not duplicating PDFBOX-1837 but this time it duplicates PDFBOX-1822. If you have more informations that can be helpful, feel free to add additional informations to this issue. I'm working at the moment on a similar issue. Maybe it also solves this problematic, Attachment damages singature Key: PDFBOX-1857 URL: https://issues.apache.org/jira/browse/PDFBOX-1857 Project: PDFBox Issue Type: Bug Components: Parsing, PDFReader, Signing, Utilities, Writing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: jack Assignee: Thomas Chojecki Priority: Blocker Attachments: attach.txt, original.pdf, original[signed].pdf, original[with-attachment].pdf, original[with-attachment][signed].pdf I have PDF document. 1) Adobe reader reads document well. 2) I sign document (using pdfbox-examples) and everything is well 3) Then I try to attach file to original PDF (Code is written in the pdfbox web page - in the cookBook). 4) Adobe reader reads attached document well. everything is well. 5) Now I have document with attachment. 6) I try to sign that document (I mean document with attachment). And I have 2 problem: First: when I open document, Adobe reader tells me that signature byte range is invalid. Second: when I try to close document (I mean to close adobe reader), Adobe reader tells me that: Do you want to save changes to original[with-attachment][signed] before closing? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878594#comment-13878594 ] Thomas Chojecki commented on PDFBOX-1822: - You are right.It looks also like a merged document. See the ID. So maybe the application merged a document that contains a classic xref table with a document that contains a xref stream. Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1848) Time Stamp Document Level Sigature
[ https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872142#comment-13872142 ] Thomas Chojecki commented on PDFBOX-1848: - Assigning tickets to you isn't possible, only committer can be assigned. But this is no problem, you can provide the patch and someone from the pdfbox team will look at the code and commit it. Time Stamp Document Level Sigature -- Key: PDFBOX-1848 URL: https://issues.apache.org/jira/browse/PDFBOX-1848 Project: PDFBox Issue Type: Improvement Components: Signing Reporter: vakhtang koroghlishvili We need TSA Document Level signature modulo too! At the moment we sign document with our certificate. But... sometimes we need to sign document with TSA too. This is important part of signing. Sometimes this is very very very important- for instance when we will implement PAdES 4 profile this module will be essential. without that Document Secure Store will not work :) I'm working on this improvement. I'will finish this soon. It's almost done. I only must add some java docs, and might be I change architect design and etc.. So, please assign this it to me :) I will upload patch as soon as possible :) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-1837) PDDocument.save(String) doesn't correctly save digital signatures
[ https://issues.apache.org/jira/browse/PDFBOX-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1837. - Resolution: Not A Problem Assignee: Thomas Chojecki The save method rewrite the document and destroy the signature. If you want to manipulate the document, you shall use only the saveIncremental method. The only problem is, that the saveIncremental method was designed for signing only. If you want to store additional content this would not work. So after signing you can only resign or need to leave the document as it is. For applying changes to the document, the COSWriter need to be extended or replaced. At the moment it does not work, so maybe in a future release we implement a fully functional incremental save. PDDocument.save(String) doesn't correctly save digital signatures - Key: PDFBOX-1837 URL: https://issues.apache.org/jira/browse/PDFBOX-1837 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.3 Reporter: Álison Fernandes Assignee: Thomas Chojecki Priority: Blocker After digitally signing a PDF, if I save it with PDDocument.save(String), Adobe Reader reports the signature as invalid. The same doesn't happen if the PDF is saved with PDDocument.saveIncremental(FileInputStream, OutputStream). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (PDFBOX-1838) PDDocument.saveIncremental should receive an InputStream instead of FileInputStream
[ https://issues.apache.org/jira/browse/PDFBOX-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1838. - Resolution: Duplicate Assignee: Thomas Chojecki This issue is known and duplicates at least PDFBOX-1614. I will fix it soon, but I haven't the environment right now to fix it. Please be patient and watch the issue PDFBOX-1614 instead. PDDocument.saveIncremental should receive an InputStream instead of FileInputStream --- Key: PDFBOX-1838 URL: https://issues.apache.org/jira/browse/PDFBOX-1838 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 1.8.3 Environment: Java Servler Reporter: Álison Fernandes Assignee: Thomas Chojecki Priority: Blocker I'm manipulating a PDF in a servlet, all of the manipulation must be done in memory. Unfortunately, the FileInputStream requirement in PDDocument.saveIncremental(FileInputStream,OutputStream) blocks me from achieving my desired implementation, as the server receives the PDF file in an InputStream. I believe that the main reason PDDocument is implemented like that is that COSWritter forces it to. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (PDFBOX-1614) Digitally sign PDFs without file system access
[
https://issues.apache.org/jira/browse/PDFBOX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-1614:
Component/s: Signing
Last year I had a conversation with Ross Woolf which I like to append to inform
the watchers about future changes to this problem.
I think there are some people waiting for this solution. The problem is, that
an InputStream can be read once or need to be buffered in the memory. For
larger documents this isn't the best way so I plan to change the way the pdfbox
parse and sign documents without doing unnecessary hacks like we do at the
moment in the saveIncremental method.
So I will fix it in two patch waves. First will be to change the
FileInputStream to InputStream and do the necessary caching inside the
pdfbox.The second will be the suggestion I mentioned in the mail at the bottom.
At present I have a web service where a document can be submitted to
the system. The web service uses MTOM as the document transport for
the web services. The code that fronts this for me hands me the
received document as an InputStream. Originally I passed this
stream, along with other data supplied in the web service to my
document management engine, which then persists the document within
the DMS. With the introduction of signing PDFs, once I get the
InputStream from the web service, I now have to save the document to
a temporary file on disk, do the signing, and then present it to the
DMS engine as a stream so that it can now persist it within the DMS.
I have an idea how to solve this.
Parsing the document the second time is only for digest creation. For
this purpose, a DigestInputStream can be used as wrapper for parsing
the document. After this, the saveIncremental need to be changed to
something like doc.saveIncremental(MessageDigest, OutputStream)
MessageDigest md = MessageDigest.getInstance(SHA-256);
InputStream is = null; // This is the incoming stream (dummy)
DigestInputStream dis = new DigestInputStream(is, md);
PDDocument doc = PDDocument.load(dis);
doc.saveIncremental(md, os); // os is the outgoing stream
The DigestInputStream use the MessageDigest object to create the digest
for the stream. In the saveIncrement the same MessageDigest will
continue digesting the bytes from the incremental update. So inside the
pdfbox, md.digest() can be used to gain the needed digest.
This change/improvement would be a larger one, but would clean the
code. I could try to implement it for the upcoming pdfbox 2.0.0 version.
I would love to be able to omit the part of having to save the temp
file during the signing and simply have my process consume the stream
and then pass it on to the DMS engine. I'm new to working with
PDF/PDFBox, so I'm just starting to learn what I can and can not do
with PDF files etc. From your comment this might be problematic due
to file sizes. At least I have it working this way for now and I
appreciate what you provided to the community to make it possible.
I know your problem and the limitation of streams make it hard to
create an easy solution for pdf signing.
I plan to create a small github project for a signing implementation
based on pdfbox and hope to get help creating something that everyone
can use for signing pdfs. At the moment every user need to write his own
implementation or use the example to do it.
Digitally sign PDFs without file system access
--
Key: PDFBOX-1614
URL: https://issues.apache.org/jira/browse/PDFBOX-1614
Project: PDFBox
Issue Type: Improvement
Components: PDModel, Signing, Writing
Affects Versions: 1.8.1
Reporter: Thierry Boschat
Assignee: Thomas Chojecki
Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
I find the sample below to handle it.
But in this example I have to use a FileInputStream however I want to do it
only through streams (without any file system access). I tried to extends
FileInputStream to deal with it but I failed. Any tips for me about that
problem ?
Thanks.
File outputDocument = new File(resources/signed + document.getName());
FileInputStream fis = new FileInputStream(document);
FileOutputStream fos = new FileOutputStream(outputDocument);
int c;
while ((c = fis.read(buffer)) != -1)
{
fos.write(buffer, 0, c);
}
fis.close();
fis = new FileInputStream(outputDocument);
// load document
PDDocument doc = PDDocument.load(document);
// create signature dictionary
PDSignature signature = new PDSignature();
signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
// subfilter for basic and PAdES Part 2 signatures
[jira] [Commented] (PDFBOX-1837) PDDocument.save(String) doesn't correctly save digital signatures
[ https://issues.apache.org/jira/browse/PDFBOX-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865323#comment-13865323 ] Thomas Chojecki commented on PDFBOX-1837: - You're right, the api doc isn't complete at this point and the method does not do what he should do for all cases. If you want to know what a incremental save do, you can look at this page http://blog.didierstevens.com/2008/05/07/solving-a-little-pdf-puzzle/ A normal save, rewrite the document from scratch. An incremental do the update at the end of the document, without touching the original one. So the document contains revisions. A fully support for incremental update isn't planned yet but I think the new pdfbox 2.x would be a candidate for that change. PDDocument.save(String) doesn't correctly save digital signatures - Key: PDFBOX-1837 URL: https://issues.apache.org/jira/browse/PDFBOX-1837 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.3 Reporter: Álison Fernandes Assignee: Thomas Chojecki Priority: Blocker After digitally signing a PDF, if I save it with PDDocument.save(String), Adobe Reader reports the signature as invalid. The same doesn't happen if the PDF is saved with PDDocument.saveIncremental(FileInputStream, OutputStream). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1836) Use the latest dependencies
[ https://issues.apache.org/jira/browse/PDFBOX-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865333#comment-13865333 ] Thomas Chojecki commented on PDFBOX-1836: - Thanks for that list. It's a shame what the bouncy castle guys doing each version, so that the lib can not be updated without code changes. Did you know how maven solve such dependency problems? As we (at the company) use pdfbox for signing we are depending on a specific version and updating bc will break the client and all libs that are build on a specific bc version. Use the latest dependencies --- Key: PDFBOX-1836 URL: https://issues.apache.org/jira/browse/PDFBOX-1836 Project: PDFBox Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Tilman Hausherr Priority: Minor Labels: maven I suggest to use the latest dependencies for the 2.0 version. Here's the output that I get by running the maven versions plugin: Building Apache FontBox 2.0.0-SNAPSHOT [versions:display-dependency-updates] The following dependencies in Dependencies have newer versions: commons-logging:commons-logging ... 1.1.1 - 1.1.3 junit:junit 4.8.1 - 4.11 Building Apache JempBox 2.0.0-SNAPSHOT [versions:display-dependency-updates] The following dependencies in Dependencies have newer versions: junit:junit 4.8.1 - 4.11 Building Apache XmpBox 2.0.0-SNAPSHOT [versions:display-dependency-updates] artifact commons-io:commons-io: checking for updates from central The following dependencies in Dependencies have newer versions: commons-io:commons-io . 1.4 - 2.4 junit:junit 4.8.1 - 4.11 Building Apache PDFBox 2.0.0-SNAPSHOT [versions:display-dependency-updates] artifact com.ibm.icu:icu4j: checking for updates from central artifact org.apache.pdfbox:fontbox: checking for updates from apache.snapshots artifact org.apache.pdfbox:jempbox: checking for updates from apache.snapshots artifact org.bouncycastle:bcmail-jdk15on: checking for updates from central artifact org.bouncycastle:bcprov-jdk15on: checking for updates from central The following dependencies in Dependencies have newer versions: com.ibm.icu:icu4j 3.8 - 52.1 commons-logging:commons-logging ... 1.1.1 - 1.1.3 junit:junit 4.8.1 - 4.11 org.bouncycastle:bcmail-jdk15on . 1.48 - 1.49 org.bouncycastle:bcprov-jdk15on . 1.48 - 1.49 Building Apache Preflight 2.0.0-SNAPSHOT [versions:display-dependency-updates] artifact org.apache.pdfbox:pdfbox: checking for updates from apache.snapshots artifact org.apache.pdfbox:xmpbox: checking for updates from apache.snapshots The following dependencies in Dependencies have newer versions: commons-io:commons-io . 1.4 - 2.4 junit:junit 4.8.1 - 4.11 log4j:log4j . 1.2.12 - 1.2.17 org.bouncycastle:bcmail-jdk15on . 1.48 - 1.49 org.bouncycastle:bcprov-jdk15on . 1.48 - 1.49 Building Apache Preflight application 2.0.0-SNAPSHOT [versions:display-dependency-updates] artifact org.apache.pdfbox:preflight: checking for updates from apache.snapshots The following dependencies in Dependencies have newer versions: commons-io:commons-io . 1.4 - 2.4 log4j:log4j . 1.2.12 - 1.2.17 org.bouncycastle:bcmail-jdk15on . 1.48 - 1.49 org.bouncycastle:bcprov-jdk15on . 1.48 - 1.49
[jira] [Commented] (PDFBOX-1823) Apache PDFBox 1.6.0 TextStripper not able to recognise characters having Frutiger LT - 45 fonts
[ https://issues.apache.org/jira/browse/PDFBOX-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859905#comment-13859905 ] Thomas Chojecki commented on PDFBOX-1823: - Did you try the latest pdfbox 1.8.3? Maybe this issue was fixed. if the issue still remains, please attach a sample document and code, so we can reproduce the issue. Apache PDFBox 1.6.0 TextStripper not able to recognise characters having Frutiger LT - 45 fonts - Key: PDFBOX-1823 URL: https://issues.apache.org/jira/browse/PDFBOX-1823 Project: PDFBox Issue Type: Bug Components: FontBox Affects Versions: 1.6.0 Environment: jdk1.6 Reporter: Chitrang Natu Labels: newbie Original Estimate: 504h Remaining Estimate: 504h When i tried to extract contents from PDF's I am successfully able to extract all text with PDFBox API but getting trouble with fonts having 'Frutiger' style. For these i am getting squared Boxes in place of characters. It seems PDFBox FontBox supports only 14 UTF characters set And none of them is Frutiger style fonts. If anybody please can suggest something. That would be of great help. I am in urgent need of the solution. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859205#comment-13859205 ] Thomas Chojecki commented on PDFBOX-1822: - I can confirm this error. The created byte range looks good. Maybe it is something else that confuse the parser or writer. The pdfbox itself can read and verify his created signature. I checked it also with the older pdfbox 1.8.2 with the same result. At the moment I have no idea whats wrong with this document. I found only a hybrid xref. Maybe there are different informations inside the xref table and the stream. I would need to analyse this case next year. Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (PDFBOX-1822) Signature byte range is Invalid
[ https://issues.apache.org/jira/browse/PDFBOX-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859205#comment-13859205 ] Thomas Chojecki edited comment on PDFBOX-1822 at 12/31/13 12:35 AM: I can confirm this error. The created byte range looks good. Maybe it is something else that confuse the parser or writer. The pdfbox itself can read and verify his created signature. I checked it also with the older pdfbox 1.8.2 with the same result. At the moment I have no idea whats wrong with this document. I found only a hybrid xref. Maybe there are different informations inside the xref table and the stream. I would need to analyse this case next year. // EDIT It's late, the document only contains a normal xref table and not hybrid references, but the pdfbox add a xref stream instead. The detection seems to not work properly. Maybe you can attach a working signed document, so I can take a look at the result. was (Author: tchojecki): I can confirm this error. The created byte range looks good. Maybe it is something else that confuse the parser or writer. The pdfbox itself can read and verify his created signature. I checked it also with the older pdfbox 1.8.2 with the same result. At the moment I have no idea whats wrong with this document. I found only a hybrid xref. Maybe there are different informations inside the xref table and the stream. I would need to analyse this case next year. Signature byte range is Invalid --- Key: PDFBOX-1822 URL: https://issues.apache.org/jira/browse/PDFBOX-1822 Project: PDFBox Issue Type: Bug Components: Parsing, PDModel, PDModel.AcroForm, Signing Affects Versions: 1.8.3, 1.8.4, 2.0.0 Reporter: vakhtang koroghlishvili Attachments: araxis-merge - compare two document.jpg, damaged-sig.jpg, unsigned-signed.pdf, unsigned.pdf On person send me a unsigned PDF document. He wanted to sign it. When I try to sign it (using pad box), I have some problem. After signing adobe reader tells me The signature byre range is invalid. I will attach original and signed document. I think, it is PDF box parser error. another signature libraries sign document very well. I'm searching the problem at the moment, in order to fix it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PDFBOX-1792) Different metadata extracted with NonSequentialPDFParser vs classic parser on some documents
[
https://issues.apache.org/jira/browse/PDFBOX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844070#comment-13844070
]
Thomas Chojecki commented on PDFBOX-1792:
-
Some files cause parsing exceptions. First I did not know if my project is
missconfigured. After checking the offsets at which the parser stop working,I
saw that some files are broken. The first one has only garbage after %%EOF. I'm
at work so I can't give you much informations about the exact files and
stacktraces.
Maybe we does not speak about the same test OR at your environment the test
can't find any files? Can you check if the file array contains at least one
testfile?
File dir = new File(src/test/resources/input);
for (File f : dir.listFiles()){
if (f.getName().toLowerCase().endsWith(.pdf)){
testSingleFileEquality(f);
}
}
Additionally I can't commit the three testfiles from the archive. See my mail
at the dev mailing list.
Different metadata extracted with NonSequentialPDFParser vs classic parser on
some documents
Key: PDFBOX-1792
URL: https://issues.apache.org/jira/browse/PDFBOX-1792
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.3
Reporter: Tim Allison
Priority: Minor
Attachments: PDFBOX-1792.tar.gz, testPDF_acroForm2.pdf
The traditional parser is able to extract metadata from a test document from
TIKA-738. The NonSequentialPDFParser is not able to extract metadata from
that file. Another file from the Tika test suite has metadata that can be
extracted by the NonSequentialPDFParser but not by classic.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (PDFBOX-1806) Metadata not completely extracted by traditional parser, but is extracted by NonSequentialParser
[ https://issues.apache.org/jira/browse/PDFBOX-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1806. - Resolution: Duplicate Please do not open new issues for known problems. Use the existing one for file upload. Both parser working different and we try our best to keep them in sync. So if you have new files or maybe more informations, just comment in PDFBOX-1792 or edit the description if necessary. Metadata not completely extracted by traditional parser, but is extracted by NonSequentialParser Key: PDFBOX-1806 URL: https://issues.apache.org/jira/browse/PDFBOX-1806 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.3 Reporter: Tim Allison Priority: Minor Attachments: testPDF_acroForm2.pdf -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (PDFBOX-1792) Metadata not completely extracted with NonSequentialPDFParser on some documents
[ https://issues.apache.org/jira/browse/PDFBOX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843625#comment-13843625 ] Thomas Chojecki commented on PDFBOX-1792: - I've run the test and there are some parsing problems with the existing testfiles in both parsers. I will commit (pdfbox 1.8.x branch) and rename the test, so it will not be run automatically. Additionally it would be great to use JUnit 4 instead of 3. So such tests can be ignored using the @Ignore annotation. Metadata not completely extracted with NonSequentialPDFParser on some documents --- Key: PDFBOX-1792 URL: https://issues.apache.org/jira/browse/PDFBOX-1792 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.3 Reporter: Tim Allison Priority: Minor Attachments: PDFBOX-1792.tar.gz The traditional parser is able to extract metadata from the Annotation test document from TIKA-738. The NonSequentialPDFParser is not able to extract metadata. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (PDFBOX-1798) Performance problem with PDDocument.saveIncremental (when signing document)
[ https://issues.apache.org/jira/browse/PDFBOX-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841446#comment-13841446 ] Thomas Chojecki commented on PDFBOX-1798: - There is a similar issue pending. PDFBOX-1614 I just forgot about it and will take some look at yours and the other issue. Performance problem with PDDocument.saveIncremental (when signing document) --- Key: PDFBOX-1798 URL: https://issues.apache.org/jira/browse/PDFBOX-1798 Project: PDFBox Issue Type: Improvement Components: PDModel, Signing Affects Versions: 1.8.3, 2.0.0 Reporter: Dmytro Karimov Labels: patch, performance Fix For: 1.8.4 Attachments: PDFBOX-1798.patch Original Estimate: 1h Remaining Estimate: 1h Performance problem in class COSWriter: Constructor of COSWriter takes 2 args: COSWriter(OutputStream os, FileInputStream is) method saveIncremental in class PDDocument: saveIncremental(FileInputStream input, OutputStream output) It create COSWriter with this args. If I pass FileInputStream into saveIncremental then signing the document goes quite a long time. If you pass BufferedInputStream, the signing speed is increases. But alas, this is not possible, because the parameters of the method saveIncremental does not allow to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PDFBOX-1792) Metadata not completely extracted with NonSequentialPDFParser on some documents
[
https://issues.apache.org/jira/browse/PDFBOX-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837927#comment-13837927
]
Thomas Chojecki commented on PDFBOX-1792:
-
The test is attached to the archive. (patch.txt)
Here is the necessary part.
PDDocument seqDoc = PDDocument.load(f);
PDDocument nonSeqDoc = PDDocument.loadNonSeq(f, new RandomAccessBuffer());
PDDocumentInformation seqInfo = seqDoc.getDocumentInformation();
PDDocumentInformation nonSeqInfo = nonSeqDoc.getDocumentInformation();
assertEquals(Metadata item count, seqInfo.getMetadataKeys().size(),
nonSeqInfo.getMetadataKeys().size());
for (String name : seqInfo.getMetadataKeys()){
assertEquals(f.getName() + :: + name,
seqInfo.getCustomMetadataValue(name),
nonSeqInfo.getCustomMetadataValue(name));
}
seqDoc.close();
nonSeqDoc.close();
Metadata not completely extracted with NonSequentialPDFParser on some
documents
---
Key: PDFBOX-1792
URL: https://issues.apache.org/jira/browse/PDFBOX-1792
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.8.3
Reporter: Tim Allison
Priority: Minor
Attachments: PDFBOX-1792.tar.gz
The traditional parser is able to extract metadata from the Annotation test
document from TIKA-738. The NonSequentialPDFParser is not able to extract
metadata.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PDFBOX-1745) PDF generated with PDFMergerUtility error out when opening.
[
https://issues.apache.org/jira/browse/PDFBOX-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828027#comment-13828027
]
Thomas Chojecki commented on PDFBOX-1745:
-
I think this issue is solved by PDFBOX-1780
Can you please test it with the latest pdfbox?
I've used the latest 1.8.3-SNAPSHOT and the follow code:
PDFMergerUtility merger = new PDFMergerUtility();
merger.addSources(Arrays.asList(new InputStream[] {
PDFMerge.class.getResourceAsStream(/pdfbox_1745/pdf_1.pdf),
PDFMerge.class.getResourceAsStream(/pdfbox_1745/pdf_2.pdf) }));
merger.setDestinationStream(new FileOutputStream(tmp/merged.pdf));
merger.mergeDocuments();
If you are using maven, you can grab the latest snapshot from the snapshot
repository
http://repository.apache.org/snapshots/
PDF generated with PDFMergerUtility error out when opening.
---
Key: PDFBOX-1745
URL: https://issues.apache.org/jira/browse/PDFBOX-1745
Project: PDFBox
Issue Type: Bug
Components: Utilities
Affects Versions: 1.8.2
Reporter: Ken Liu
Priority: Blocker
Attachments: merged_bad.pdf, pdf_1.pdf, pdf_2.pdf
Two pdf files - pdf_1 and pdf_2, after merged by PDFMergerUtility,
pdf_1 + pdf_2: error out when opening the merged pdf, when browsing down to
the pdf_2 part.
pdf_2 + pdf_1: works.
This issue is different than PDFBOX-515. for this problem, pdf is gernerated
in both way, but when opening, get errors.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (PDFBOX-1745) PDF generated with PDFMergerUtility error out when opening.
[ https://issues.apache.org/jira/browse/PDFBOX-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1745: Attachment: merged.pdf PDF generated with PDFMergerUtility error out when opening. --- Key: PDFBOX-1745 URL: https://issues.apache.org/jira/browse/PDFBOX-1745 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.8.2 Reporter: Ken Liu Priority: Blocker Attachments: merged.pdf, merged_bad.pdf, pdf_1.pdf, pdf_2.pdf Two pdf files - pdf_1 and pdf_2, after merged by PDFMergerUtility, pdf_1 + pdf_2: error out when opening the merged pdf, when browsing down to the pdf_2 part. pdf_2 + pdf_1: works. This issue is different than PDFBOX-515. for this problem, pdf is gernerated in both way, but when opening, get errors. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PDFBOX-1714) Merging PDFs results in java.io.IOException: expected='R' actual='0'
[ https://issues.apache.org/jira/browse/PDFBOX-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13828072#comment-13828072 ] Thomas Chojecki commented on PDFBOX-1714: - I've tried to reproduce it with the latest 1.8.3-SNAPSHOT, but it seems to be solved. I merged the doc1 with doc2 to a new document. Then took the new document and merged it with doc2. The result looks fine. Maybe this issue that is similar to PDFBOX-1745 is also solved with the patch from PDFBOX-1780. Can someone try to reproduce it again? I used the same code as described in PDFBOX-1745. Merging PDFs results in java.io.IOException: expected='R' actual='0' Key: PDFBOX-1714 URL: https://issues.apache.org/jira/browse/PDFBOX-1714 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.2 Reporter: Gerhard Temper Attachments: doc1.pdf, doc2.pdf Merging attached files results in a PDF which isn't processable by PDFBox. Merging or editing the resulting PDF results in an exception: java.io.IOException: expected='R' actual='0' D:\pdfboxtestjava -jar pdfbox-app-1.8.2.jar PDFMerger doc1.pdf doc2.pdf result.pdf D:\pdfboxtestjava -jar pdfbox-app-1.8.2.jar PDFMerger result.pdf doc2.pdf result2.pdf Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Bad Dictionary Declaration org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Bad Dictionary Declaration org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Bad Dictionary Declaration org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Bad Dictionary Declaration org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Bad Dictionary Declaration org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' Sep 05, 2013 8:18:48 AM org.apache.pdfbox.pdfparser.BaseParser parseCOSDictionary WARNING: Invalid dictionary, found: 'e' but expected: '/' PDFMerger failed with the following exception: java.io.IOException: expected='R' actual='0' org.apache.pdfbox.io.PushBackInputStream@7a4b35d5 at org.apache.pdfbox.pdfparser.BaseParser.parseCOSDictionaryValue(BaseParser.java:233) at org.apache.pdfbox.pdfparser.BaseParser.parseCOSDictionary(BaseParser.java:349) at org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1236) at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:559) at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:188) at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1192) at org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:1159) at org.apache.pdfbox.util.PDFMergerUtility.mergeDocuments(PDFMergerUtility.java:181) at org.apache.pdfbox.PDFMerger.merge(PDFMerger.java:68) at org.apache.pdfbox.PDFMerger.main(PDFMerger.java:44) at org.apache.pdfbox.PDFBox.main(PDFBox.java:83) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PDFBOX-1766) [PATCH] Visible Signature using PDFbox
[ https://issues.apache.org/jira/browse/PDFBOX-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1766. - Resolution: Fixed Fix Version/s: 2.0.0 1.8.3 Added your last patch in revision 1542291 of pdfbox 2.0.0 Thx again for contributing [~lehmi] Can you please cherrypick these patches and add them to the 1.8.3 release? Thx in advance [PATCH] Visible Signature using PDFbox -- Key: PDFBOX-1766 URL: https://issues.apache.org/jira/browse/PDFBOX-1766 Project: PDFBox Issue Type: New Feature Components: PDModel, Signing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Thomas Chojecki Priority: Critical Labels: patch, signature, visual Fix For: 1.8.3, 2.0.0 Attachments: Docs_Update.patch, Signature.jpg, VisibleSignature.patch, sample.pdf In order to sign document with visible signature we have very bad solution at the moment: passing a PDF as an InputStream that serves as a template for the appearance settings is very inconvenient. So, Now Everything is well and fixed! You only set image with location, zoom, width, height, and etc, and everything will be added automatically. I've just already done this, and I will upload my patches too. I have wrote example too, in order to see how to use it. Everything is easy! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PDFBOX-1314) PDFParser should set direct property in COSBase if this object is direct
[ https://issues.apache.org/jira/browse/PDFBOX-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1314. - Resolution: Duplicate was fixed with PDFBOX-1780 PDFParser should set direct property in COSBase if this object is direct -- Key: PDFBOX-1314 URL: https://issues.apache.org/jira/browse/PDFBOX-1314 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 1.6.0 Reporter: Petras Labels: COSWriter, PDFParser Attachments: sample_signed_with_increment.pdf PDFParser during PDF parsing does not update COSBase#direct property - it always return false when read. Especially this issue manifests for dictionary objects when PDF is saved (either regularly or incrementally) - all dictionary objects in saved PDF, if they do not have COSBase#direct property set or are not specifically treated by COSWriter (like XObject or Resources) are written as indirect objects. Though PDF specification allows dictionary objects to be indirect, but not for /Extensions dictionary in document catalog: The extensions dictionary, all developer extensions dictionary entries in the extensions dictionary, as well as their entries, all shall be direct objects (i.e., this information shall be nested directly within the catalog dictionary with no indirect objects used). (see ISO 32000-1: 7.12 Extensions Dictionary). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PDFBOX-1370) Only the last visual signature is valid when multiple signatures have been added on different pages
[ https://issues.apache.org/jira/browse/PDFBOX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1370. - Resolution: Duplicate was fixed with PDFBOX-1780 Only the last visual signature is valid when multiple signatures have been added on different pages --- Key: PDFBOX-1370 URL: https://issues.apache.org/jira/browse/PDFBOX-1370 Project: PDFBox Issue Type: Bug Affects Versions: 1.6.0, 1.7.1 Reporter: Matthias Küng Assignee: Thomas Chojecki Attachments: doublesigned.png, pdfbox-1370.zip * Every visual signature that is added invalidates the previous ones (Adobe Reader displays the message that the document has changed) * If the signatures are added to different pages only the ones that have been added to the page of the last one are visible in PDFReader (Adobe displays the message in the signature view that the form field has been deleted) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PDFBOX-1780) previous revision is damaged after signing
[ https://issues.apache.org/jira/browse/PDFBOX-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13822986#comment-13822986 ] Thomas Chojecki commented on PDFBOX-1780: - Big thanks for this patch. previous revision is damaged after signing -- Key: PDFBOX-1780 URL: https://issues.apache.org/jira/browse/PDFBOX-1780 Project: PDFBox Issue Type: Bug Components: Parsing, Signing, Writing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Andreas Lehmkühler Priority: Critical Fix For: 1.8.3, 2.0.0 Attachments: fixed.jpg, fixed.patch, original-signed -[FIXED].pdf, original-signed [DAMAGED].pdf, original-signed [ORIGINAL].pdf Ihave PDF file which was signed by some other application. When I try to sign it with PDFbox, previous revision is damaged. I have discussion at stackoverflow, with Michael Klink. http://stackoverflow.com/questions/19903884/pdf-document-is-modified-by-another-revision/19905271?noredirect=1#19905271 when we see some changes merely was structural. Some changes was just rounding problem - PDFBOX-1778. When I test, problem of damaged signature was caused from structural change [when there must be direct reference, there was indirect reference and etc..] So we solve that problem. I will upload damaged PDF document, fixed pdf, and the patch too. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PDFBOX-1751) Signing external signed document again with pdfbox, break the document.
[
https://issues.apache.org/jira/browse/PDFBOX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki resolved PDFBOX-1751.
-
Resolution: Duplicate
was fixed with PDFBOX-1780
Signing external signed document again with pdfbox, break the document.
---
Key: PDFBOX-1751
URL: https://issues.apache.org/jira/browse/PDFBOX-1751
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 1.8.0, 1.8.1, 1.8.2
Environment: Windows 8.1
Reporter: David KELLER
Assignee: Thomas Chojecki
Labels: security, signature
Attachments: PADESSigner.java, contract.pdf,
contract.pdf_signedIText.pdf, contract.pdf_signedPdfBox.pdf,
contract_signed_Cryptolog.pdf
1/ I sign a file using this method
public static void signByPdfbox(
File inputPDF,
File outputPDF,
KeyStore ks,
String password)
throws IOException, UnrecoverableKeyException, KeyStoreException,
NoSuchAlgorithmException, COSVisitorException, SignatureException {
PDDocument inputDoc = PDDocument.load(inputPDF);
PADESSigner signer = new PADESSigner(ks, password);
signer.setSignatureName(Hello1);
signer.setSignatureReason(Why noy);
signer.setSignatureLocation(Curacao);
signer.setSignatureContactInfo(david.keller...@gmail.com);
signer.signPDF(inputDoc, outputPDF);
}
2/ I resign the same file using the same method and in acrobat reader I have
this error : SignDict/Contents illegal data
I have googelized it, and I found only old topics for iText lib.
I have tried the same with iText 5.X, and double signatures works
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PDFBOX-1766) [PATCH] Visible Signature using PDFbox
[ https://issues.apache.org/jira/browse/PDFBOX-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13821561#comment-13821561 ] Thomas Chojecki commented on PDFBOX-1766: - fixed in revision 1541625 for pdfbox 2.0.0 patch for 1.8.3 is coming soon Can you please take a look at the commit? I have done some little changes, most of them typo, licence headers and one improvement inside the SignatureOptions object. With the typo changes some method names changed. Maybe it will be incompatible to your software. Please give me a feedback to this commit, so I can close the issue. Again thx for providing this patch/improvement :-) [PATCH] Visible Signature using PDFbox -- Key: PDFBOX-1766 URL: https://issues.apache.org/jira/browse/PDFBOX-1766 Project: PDFBox Issue Type: New Feature Components: PDModel, Signing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Priority: Critical Labels: patch, signature, visual Attachments: VisibleSignature.patch In order to sign document with visible signature we have very bad solution at the moment: passing a PDF as an InputStream that serves as a template for the appearance settings is very inconvenient. So, Now Everything is well and fixed! You only set image with location, zoom, width, height, and etc, and everything will be added automatically. I've just already done this, and I will upload my patches too. I have wrote example too, in order to see how to use it. Everything is easy! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (PDFBOX-1766) [PATCH] Visible Signature using PDFbox
[ https://issues.apache.org/jira/browse/PDFBOX-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki reassigned PDFBOX-1766: --- Assignee: Thomas Chojecki [PATCH] Visible Signature using PDFbox -- Key: PDFBOX-1766 URL: https://issues.apache.org/jira/browse/PDFBOX-1766 Project: PDFBox Issue Type: New Feature Components: PDModel, Signing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Assignee: Thomas Chojecki Priority: Critical Labels: patch, signature, visual Attachments: VisibleSignature.patch In order to sign document with visible signature we have very bad solution at the moment: passing a PDF as an InputStream that serves as a template for the appearance settings is very inconvenient. So, Now Everything is well and fixed! You only set image with location, zoom, width, height, and etc, and everything will be added automatically. I've just already done this, and I will upload my patches too. I have wrote example too, in order to see how to use it. Everything is easy! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PDFBOX-1766) [PATCH] Visible Signature using PDFbox
[ https://issues.apache.org/jira/browse/PDFBOX-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1766: Affects Version/s: (was: 1.8.3) (was: 2.0.0) 1.8.2 Fix Version/s: (was: 1.8.3) (was: 1.8.2) Labels: patch signature visual (was: patch) Remaining Estimate: (was: 168h) Original Estimate: (was: 168h) Many thanks for this patch. I took yesterday a first look and it work really nice. I think this can also help people doing visual signatures with text, embedded as an image. I try to test the code first and give you soon some feedback. [PATCH] Visible Signature using PDFbox -- Key: PDFBOX-1766 URL: https://issues.apache.org/jira/browse/PDFBOX-1766 Project: PDFBox Issue Type: New Feature Components: PDModel, Signing Affects Versions: 1.8.2 Reporter: vakhtang koroghlishvili Priority: Critical Labels: patch, signature, visual Attachments: VisibleSignature.patch In order to sign document with visible signature we have very bad solution at the moment: passing a PDF as an InputStream that serves as a template for the appearance settings is very inconvenient. So, Now Everything is well and fixed! You only set image with location, zoom, width, height, and etc, and everything will be added automatically. I've just already done this, and I will upload my patches too. I have wrote example too, in order to see how to use it. Everything is easy! -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PDFBOX-1751) SignDict/Contents illegal data
[
https://issues.apache.org/jira/browse/PDFBOX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809242#comment-13809242
]
Thomas Chojecki commented on PDFBOX-1751:
-
can you attach the class you are currently using with the made changes.
optional it would be also good to see the double signed document that the
pdfbox created.
SignDict/Contents illegal data
--
Key: PDFBOX-1751
URL: https://issues.apache.org/jira/browse/PDFBOX-1751
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 1.8.0
Environment: Windows 8.1
Reporter: David KELLER
Assignee: Thomas Chojecki
Labels: security, signature
Attachments: contract.pdf, contract.pdf_signedIText.pdf,
contract.pdf_signedPdfBox.pdf, PADESSigner.java
1/ I sign a file using this method
public static void signByPdfbox(
File inputPDF,
File outputPDF,
KeyStore ks,
String password)
throws IOException, UnrecoverableKeyException, KeyStoreException,
NoSuchAlgorithmException, COSVisitorException, SignatureException {
PDDocument inputDoc = PDDocument.load(inputPDF);
PADESSigner signer = new PADESSigner(ks, password);
signer.setSignatureName(Hello1);
signer.setSignatureReason(Why noy);
signer.setSignatureLocation(Curacao);
signer.setSignatureContactInfo(david.keller...@gmail.com);
signer.signPDF(inputDoc, outputPDF);
}
2/ I resign the same file using the same method and in acrobat reader I have
this error : SignDict/Contents illegal data
I have googelized it, and I found only old topics for iText lib.
I have tried the same with iText 5.X, and double signatures works
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (PDFBOX-1751) Signing external signed document again with pdfbox, break the document.
[
https://issues.apache.org/jira/browse/PDFBOX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-1751:
Affects Version/s: 1.8.1
1.8.2
Summary: Signing external signed document again with pdfbox,
break the document. (was: SignDict/Contents illegal data)
Signing external signed document again with pdfbox, break the document.
---
Key: PDFBOX-1751
URL: https://issues.apache.org/jira/browse/PDFBOX-1751
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 1.8.0, 1.8.1, 1.8.2
Environment: Windows 8.1
Reporter: David KELLER
Assignee: Thomas Chojecki
Labels: security, signature
Attachments: contract.pdf, contract.pdf_signedIText.pdf,
contract.pdf_signedPdfBox.pdf, contract_signed_Cryptolog.pdf, PADESSigner.java
1/ I sign a file using this method
public static void signByPdfbox(
File inputPDF,
File outputPDF,
KeyStore ks,
String password)
throws IOException, UnrecoverableKeyException, KeyStoreException,
NoSuchAlgorithmException, COSVisitorException, SignatureException {
PDDocument inputDoc = PDDocument.load(inputPDF);
PADESSigner signer = new PADESSigner(ks, password);
signer.setSignatureName(Hello1);
signer.setSignatureReason(Why noy);
signer.setSignatureLocation(Curacao);
signer.setSignatureContactInfo(david.keller...@gmail.com);
signer.signPDF(inputDoc, outputPDF);
}
2/ I resign the same file using the same method and in acrobat reader I have
this error : SignDict/Contents illegal data
I have googelized it, and I found only old topics for iText lib.
I have tried the same with iText 5.X, and double signatures works
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (PDFBOX-1370) Only the last visual signature is valid when multiple signatures have been added on different pages
[ https://issues.apache.org/jira/browse/PDFBOX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1370: Summary: Only the last visual signature is valid when multiple signatures have been added on different pages (was: Only the last visual signature is valid when multiple signatures have been added) Only the last visual signature is valid when multiple signatures have been added on different pages --- Key: PDFBOX-1370 URL: https://issues.apache.org/jira/browse/PDFBOX-1370 Project: PDFBox Issue Type: Bug Affects Versions: 1.6.0, 1.7.1 Reporter: Matthias Küng Assignee: Thomas Chojecki Attachments: doublesigned.png, pdfbox-1370.zip * Every visual signature that is added invalidates the previous ones (Adobe Reader displays the message that the document has changed) * If the signatures are added to different pages only the ones that have been added to the page of the last one are visible in PDFReader (Adobe displays the message in the signature view that the form field has been deleted) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (PDFBOX-1751) SignDict/Contents illegal data
[
https://issues.apache.org/jira/browse/PDFBOX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki closed PDFBOX-1751.
---
Resolution: Not A Problem
Assignee: Thomas Chojecki
The method signPDF(PDDocument inputDoc ...) malform the document.
inputDoc.save() will rewrite the signed document and broke the signature.
You need to use the method signPDF(byte[] ) to do it the right way.
Maybe something like this
public static void main(String[] args) throws Exception
{
String pin = 123456;
File out = new File(tmp/Sample_signed.pdf);
File out2 = new File(tmp/Sample_signed_signed.pdf);
KeyStore keystore = null;
try (InputStream documentIS =
PADESSigner.class.getResourceAsStream(/pdfbox_1751/Sample.pdf);
InputStream keystoreIS =
PADESSigner.class.getResourceAsStream(/pdfbox_1751/Author01.p12);) {
keystore = KeyStore.getInstance(pkcs12);
keystore.load(keystoreIS, pin.toCharArray());
PADESSigner padesSigner = new PADESSigner(keystore, pin);
padesSigner.setSignatureName(Testing);
padesSigner.signPDF(IOUtils.toByteArray(documentIS), out);
}
try (InputStream documentIS = new FileInputStream(out);) {
PADESSigner padesSigner = new PADESSigner(keystore, pin);
padesSigner.setSignatureName(Testing);
padesSigner.signPDF(IOUtils.toByteArray(documentIS), out2);
}
}
SignDict/Contents illegal data
--
Key: PDFBOX-1751
URL: https://issues.apache.org/jira/browse/PDFBOX-1751
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 1.8.0
Environment: Windows 8.1
Reporter: David KELLER
Assignee: Thomas Chojecki
Labels: security, signature
Attachments: PADESSigner.java
1/ I sign a file using this method
public static void signByPdfbox(
File inputPDF,
File outputPDF,
KeyStore ks,
String password)
throws IOException, UnrecoverableKeyException, KeyStoreException,
NoSuchAlgorithmException, COSVisitorException, SignatureException {
PDDocument inputDoc = PDDocument.load(inputPDF);
PADESSigner signer = new PADESSigner(ks, password);
signer.setSignatureName(Hello1);
signer.setSignatureReason(Why noy);
signer.setSignatureLocation(Curacao);
signer.setSignatureContactInfo(david.keller...@gmail.com);
signer.signPDF(inputDoc, outputPDF);
}
2/ I resign the same file using the same method and in acrobat reader I have
this error : SignDict/Contents illegal data
I have googelized it, and I found only old topics for iText lib.
I have tried the same with iText 5.X, and double signatures works
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PDFBOX-1261) Support for visual signature without a pdf template
[ https://issues.apache.org/jira/browse/PDFBOX-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13778645#comment-13778645 ] Thomas Chojecki commented on PDFBOX-1261: - [~v.koroghlishvili] Maybe you can contribute your code / library so we can implement it in a future release. I think many user are waiting for this feature. Support for visual signature without a pdf template --- Key: PDFBOX-1261 URL: https://issues.apache.org/jira/browse/PDFBOX-1261 Project: PDFBox Issue Type: New Feature Components: PDModel Affects Versions: 1.6.0 Reporter: Matthias Küng It would be very nice to set an image (of a hand written signature) along with the position and dimension of the visible signature field to the SignatureOptions which are interpreted in PDDocument.addSignature(). The current solution with passing a pdf as InputStream that serves as a template for the appearance settings is very inconvenient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PDFBOX-1370) Only the last visual signature is valid when multiple signatures have been added
[ https://issues.apache.org/jira/browse/PDFBOX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki reassigned PDFBOX-1370: --- Assignee: Thomas Chojecki Only the last visual signature is valid when multiple signatures have been added Key: PDFBOX-1370 URL: https://issues.apache.org/jira/browse/PDFBOX-1370 Project: PDFBox Issue Type: Bug Affects Versions: 1.6.0, 1.7.1 Reporter: Matthias Küng Assignee: Thomas Chojecki Attachments: doublesigned.png, pdfbox-1370.zip * Every visual signature that is added invalidates the previous ones (Adobe Reader displays the message that the document has changed) * If the signatures are added to different pages only the ones that have been added to the page of the last one are visible in PDFReader (Adobe displays the message in the signature view that the form field has been deleted) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PDFBOX-1726) PDDocument.load() freezes while loading certain types of documents (Infinity load)
[
https://issues.apache.org/jira/browse/PDFBOX-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki closed PDFBOX-1726.
---
Resolution: Duplicate
PDDocument.load() freezes while loading certain types of documents (Infinity
load)
--
Key: PDFBOX-1726
URL: https://issues.apache.org/jira/browse/PDFBOX-1726
Project: PDFBox
Issue Type: Bug
Reporter: Demétrius Jubé
When trying to load the document located at
http://web.itu.edu.tr/~pazarci/rtv/TEK_Digital%20Video%20Measurements_25W_14700_3.pdf,
the system halts and never come back. It does not exit and does not print
any error message. It just stops at PDDocument.load() and does not continue.
Here are the steps to reproduce (Assuming that the file is located at docPath
variable):
{code}
FileInputStream file = new FileInputStream(docPath);
PDDocument documento = PDDocument.load(stream, true);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1720) BouncyCastle 1.49: ambigous constructor usage
[ https://issues.apache.org/jira/browse/PDFBOX-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13769312#comment-13769312 ] Thomas Chojecki commented on PDFBOX-1720: - This solution did not work with 1.48. Cannot cast from DEROctetString to ASN1Set Nevertheless, it is a good idea to support a wide range of BouncyCastle versions. The refactoring of BC slowly becoming annoying. BouncyCastle 1.49: ambigous constructor usage - Key: PDFBOX-1720 URL: https://issues.apache.org/jira/browse/PDFBOX-1720 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: Tilman Hausherr Priority: Minor pdfbox\pdmodel\encryption\PublicKeySecurityHandler.java: EnvelopedData env = new EnvelopedData(null, derset, encryptedcontentinfo, null); is ambigous *if* one would use the latest (1.49) version of bouncycastle and doesn't compile. One has to choose one of the two constructors by setting a type for the last null. Looking at the constructor for 1.49, the solution would be: Solution: EnvelopedData env = new EnvelopedData(null, derset, encryptedcontentinfo, (ASN1Set) null); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1720) BouncyCastle 1.49: ambigous constructor usage
[ https://issues.apache.org/jira/browse/PDFBOX-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1720. - Resolution: Fixed Fix Version/s: 2.0.0 Assignee: Thomas Chojecki Gosh. You're right. Skipped the line. I fixed it in rev 1523961 BouncyCastle 1.49: ambigous constructor usage - Key: PDFBOX-1720 URL: https://issues.apache.org/jira/browse/PDFBOX-1720 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.0 Reporter: Tilman Hausherr Assignee: Thomas Chojecki Priority: Minor Fix For: 2.0.0 pdfbox\pdmodel\encryption\PublicKeySecurityHandler.java: EnvelopedData env = new EnvelopedData(null, derset, encryptedcontentinfo, null); is ambigous *if* one would use the latest (1.49) version of bouncycastle and doesn't compile. One has to choose one of the two constructors by setting a type for the last null. Looking at the constructor for 1.49, the solution would be: Solution: EnvelopedData env = new EnvelopedData(null, derset, encryptedcontentinfo, (ASN1Set) null); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1716) PDDocument.getNumberOfPages() return 0 for certain PDF document
[
https://issues.apache.org/jira/browse/PDFBOX-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13768119#comment-13768119
]
Thomas Chojecki commented on PDFBOX-1716:
-
I've tested it against the last 1.8.3 Snapshot.
The document is encrypted and use a objectstream for the pages. At the moment
the objectstreams will be resolved on document decryption. So if you decrypt
the document first, it should work fine.
So try to do something like this:
pdDoc = new PDDocument(cosDoc);
pdDoc.decrypt();
pdDoc.getNumberOfPages()
The PDDocument also provide a function isEncrypted() which will return true in
case the document is encrypted at the moment. After decrypting it will return
false.
This should also work for at least pdfbox 1.8.2.
PDDocument.getNumberOfPages() return 0 for certain PDF document
---
Key: PDFBOX-1716
URL: https://issues.apache.org/jira/browse/PDFBOX-1716
Project: PDFBox
Issue Type: Bug
Components: Parsing
Affects Versions: 1.8.2
Reporter: Tom
Fix For: 1.8.2
Sample
document(https://issues.apache.org/jira/secure/attachment/12430914/FormI-9-English.pdf)
can be found here https://issues.apache.org/jira/browse/PDFBOX-578. Looks
the NPE issue fix in that work item
https://issues.apache.org/jira/browse/PDFBOX-578 is a work around.
When I try to extract the text content from /FormI-9-English.pdf , when I
call PDDocument.getNumberOfPages(), this method return 0 which makes the
extraction of the text content impossible:
InputStream in = PDF InputStream
PDFParser parser = new PDFParser(content);
PDFTextStripper pdfStripper = null;
String parsedText = null;
parser.parse();
cosDoc = parser.getDocument();
pdfStripper = new PDFTextStripper();
pdDoc = new PDDocument(cosDoc);
for(int i=1; i= pdDoc.getNumberOfPages(); i++)
{ // pdDoc.getNumberOfPages() return 0, which is incorrect
}
Note:
1. This problem is found in the PDFBox latest version 1.8.2
2. I didn't which component to file this defect, so please assign to the
correct component if needed, Thanks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1719) NPE while signing PDF - acroform without fields
Thomas Chojecki created PDFBOX-1719: --- Summary: NPE while signing PDF - acroform without fields Key: PDFBOX-1719 URL: https://issues.apache.org/jira/browse/PDFBOX-1719 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.2 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Fix For: 1.8.3, 2.0.0 Trying to sign a document that has already an AcroForm but no fields cause a NullPointerException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1719) NPE while signing PDF - acroform without fields
[ https://issues.apache.org/jira/browse/PDFBOX-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1719. - Resolution: Fixed Fixed in rev 1523680 for 2.0.0 1523675 for 1.8.3 NPE while signing PDF - acroform without fields --- Key: PDFBOX-1719 URL: https://issues.apache.org/jira/browse/PDFBOX-1719 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.2 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Fix For: 1.8.3, 2.0.0 Trying to sign a document that has already an AcroForm but no fields cause a NullPointerException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1614) Digitally sign PDFs without file system access
[
https://issues.apache.org/jira/browse/PDFBOX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13676761#comment-13676761
]
Thomas Chojecki commented on PDFBOX-1614:
-
I've created a snapshot with the given changes. Haven't test it yet, so if you
want to check it out, you can grab it from
http://people.apache.org/~tchojecki/PDFBOX-1614/
The code need bc in the version jdk15on-1.48
Digitally sign PDFs without file system access
--
Key: PDFBOX-1614
URL: https://issues.apache.org/jira/browse/PDFBOX-1614
Project: PDFBox
Issue Type: Improvement
Components: PDModel, Writing
Affects Versions: 1.8.1
Reporter: Thierry Boschat
Assignee: Thomas Chojecki
Hi I'm using pdfbox-1.8.1 to digitally sign PDFs.
I find the sample below to handle it.
But in this example I have to use a FileInputStream however I want to do it
only through streams (without any file system access). I tried to extends
FileInputStream to deal with it but I failed. Any tips for me about that
problem ?
Thanks.
File outputDocument = new File(resources/signed + document.getName());
FileInputStream fis = new FileInputStream(document);
FileOutputStream fos = new FileOutputStream(outputDocument);
int c;
while ((c = fis.read(buffer)) != -1)
{
fos.write(buffer, 0, c);
}
fis.close();
fis = new FileInputStream(outputDocument);
// load document
PDDocument doc = PDDocument.load(document);
// create signature dictionary
PDSignature signature = new PDSignature();
signature.setFilter(PDSignature.FILTER_ADOBE_PPKLITE); // default filter
// subfilter for basic and PAdES Part 2 signatures
signature.setSubFilter(PDSignature.SUBFILTER_ADBE_PKCS7_DETACHED);
signature.setName(signer name);
signature.setLocation(signer location);
signature.setReason(reason for signature);
// the signing date, needed for valid signature
signature.setSignDate(Calendar.getInstance());
// register signature dictionary and sign interface
doc.addSignature(signature, this);
// write incremental (only for signing purpose)
doc.saveIncremental(fis, fos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1613) The ability to inject the time/random component into the COSWriter process to write a PDF document allows some advanced signature creation scenarios where the signatur
[ https://issues.apache.org/jira/browse/PDFBOX-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671565#comment-13671565 ] Thomas Chojecki commented on PDFBOX-1613: - Maybe I miss a use case or it was just late and I make a mistake. Here a part of the code from COSWriter Long idTime = doc.getDocumentId() == null ? System.currentTimeMillis() : doc.getDocumentId(); if documentId was not set (default case), we use the the current timestamp, otherwise we use the documentId that the user set. The document id will only be fix if someone set the documentId through the setter, otherwise it will be always the timestamp. The normal use case will be, creating or loading a pdf. After alter the document and saving it, a new ID will be generated each time. The only case where the ID stay fix is if the user set this Id through the setter and save the document. Normally a user will save the document once. After this maybe it will open the document once again and create a new PDDocument object which will use the default behavior (current timestamp) and not the fixed one. If a user using the PDDocument object more than one time for saving (don't know a reason for this) he can set the documentId to null ( #setDocumentId(null) ) so he will get the old behavior. I think this setter turn on a specific feature, so the user will know what he is doing. Please correct me if I'm wrong. I have no feeling if this is good or bad, but it makes it possible using only the convenience classes to set an Id. Your original code inject the Id in the COSWriter which is a low level api call. Normally a user do not trigger the COSWriter.write(pdDocument) directly. For this, he will need to understand what happens behind the scene ( #saveIncremental()) Best regards Thomas The ability to inject the time/random component into the COSWriter process to write a PDF document allows some advanced signature creation scenarios where the signature is generated on a separate server that does not hold the full PDF document. Key: PDFBOX-1613 URL: https://issues.apache.org/jira/browse/PDFBOX-1613 Project: PDFBox Issue Type: Improvement Components: Writing Affects Versions: 1.8.1 Environment: Any Reporter: Stefan Santesson Assignee: Thomas Chojecki Priority: Minor Labels: security Fix For: 2.0.0 I have developed a prototype server based signing service for the Swedish National eID infrastructure. I'll skip the details, but I recently switched to PDFBox for the PDF signing process and it works great. However, I had to modify the COSWriter class to get this working. I'm writing to check whether you would consider adding the functionality I need to future version of PDFBox. The problem is the the signature service is just producing the signature, it is not trusted to handle the PDF document. The government service having the PDF document signed is using PDFBox in a 2 step process. 1) To produce the SignedAttributes DER Object of the CMS signature to be created. This is the part that is hashed and signed by the signature service. 2) After receiving the signature and signature certs from the signature service, completing the PDF signature by delivering the complete PKCS#7 object to PDFBox using the externally generated signature value and certs. There are probably a more pure way to handle this, but Since PDFBox allows me to create a signature interface that produces the SignedData. I found it to be the easiest way to run the signature process 2 times. 1st pass using dummy key and dummy certs. This only to obtain the SignedAttributes. 2nd pass by delivering a SignedData object that include the Signature value and certs produced by the signature service. Now in order to do this, I have to control the random seed added by the COSWriter, or else the signature created by the signature service will not match the hash in the SignedAttributes produced in the second pass. My modification is provided below. I simply provided an extra input parameter to the write function where I can provide the long seed I then added a backwards compatible write function where the long seed is current time. By providing the same seed to pass 1 and pass 2, I can get the externally created signature to match the SignedAttributes produced in the first pass. The write function below is identical to the original COSWriter function except that it takes the idTime value from the function input parameter instead of
[jira] [Updated] (PDFBOX-1613) The ability to inject the time/random component into the COSWriter process to write a PDF document allows some advanced signature creation scenarios where the signature
[
https://issues.apache.org/jira/browse/PDFBOX-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki updated PDFBOX-1613:
Fix Version/s: 2.0.0
Fixed in revision 1488049
I've done some changes to the code. The PDDocument got a new getter and setter
setDocumentId(Long id). If this value isn't null, it will be used for the id
generation in the COSWriter. So it will be more intuitive to use (I hope)
If this isn't what you are searching for, then let me know :-) I will give you
also a replay to your mail, please stay patient.
The ability to inject the time/random component into the COSWriter process to
write a PDF document allows some advanced signature creation scenarios where
the signature is generated on a separate server that does not hold the full
PDF document.
Key: PDFBOX-1613
URL: https://issues.apache.org/jira/browse/PDFBOX-1613
Project: PDFBox
Issue Type: Improvement
Components: Writing
Affects Versions: 1.8.1
Environment: Any
Reporter: Stefan Santesson
Assignee: Thomas Chojecki
Priority: Minor
Labels: security
Fix For: 2.0.0
I have developed a prototype server based signing service for the Swedish
National eID infrastructure.
I'll skip the details, but I recently switched to PDFBox for the PDF signing
process and it works great. However, I had to modify the COSWriter class to
get this working.
I'm writing to check whether you would consider adding the functionality I
need to future version of PDFBox.
The problem is the the signature service is just producing the signature, it
is not trusted to handle the PDF document.
The government service having the PDF document signed is using PDFBox in a 2
step process.
1) To produce the SignedAttributes DER Object of the CMS signature to be
created. This is the part that is hashed and signed by the signature service.
2) After receiving the signature and signature certs from the signature
service, completing the PDF signature by delivering the complete PKCS#7
object to PDFBox using the externally generated signature value and certs.
There are probably a more pure way to handle this, but Since PDFBox allows me
to create a signature interface that produces the SignedData. I found it to
be the easiest way to run the signature process 2 times.
1st pass using dummy key and dummy certs. This only to obtain the
SignedAttributes.
2nd pass by delivering a SignedData object that include the Signature value
and certs produced by the signature service.
Now in order to do this, I have to control the random seed added by the
COSWriter, or else the signature created by the signature service will not
match the hash in the SignedAttributes produced in the second pass.
My modification is provided below.
I simply provided an extra input parameter to the write function where I can
provide the long seed
I then added a backwards compatible write function where the long seed is
current time.
By providing the same seed to pass 1 and pass 2, I can get the externally
created signature to match the SignedAttributes produced in the first pass.
The write function below is identical to the original COSWriter function
except that it takes the idTime value from the function input parameter
instead of getting it from System.currentTimeMillis().
Modified functions of COSWriter:
/**
* This will write the pdf document.
*
* @param doc The document to write.
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc) throws COSVisitorException {
write(doc, System.currentTimeMillis());
}
/**
* This will write the pdf document.
*
* @param doc The document to write.
* @param idTime The time seed used to generate the id
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc, long idTime) throws COSVisitorException {
document = doc;
if (incrementalUpdate) {
prepareIncrement(doc);
}
// if the document says we should remove encryption, then we shouldn't
encrypt
if (doc.isAllSecurityToBeRemoved()) {
this.willEncrypt = false;
// also need to get rid of the Encrypt in the trailer so readers
// don't try to decrypt a document which is not encrypted
COSDocument cosDoc = doc.getDocument();
COSDictionary trailer = cosDoc.getTrailer();
[jira] [Updated] (PDFBOX-1591) Resources should implement java.io.closeable
[ https://issues.apache.org/jira/browse/PDFBOX-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1591: Fix Version/s: 2.0.0 Fixed in revision 1488058 and 1488059. Forgot to alter the COSDocument, so we got two revs. If you find more resources that implements a close method and are public visible, give me a note. This two resources are the most used one, hope this help. Resources should implement java.io.closeable Key: PDFBOX-1591 URL: https://issues.apache.org/jira/browse/PDFBOX-1591 Project: PDFBox Issue Type: Improvement Components: PDModel Reporter: Stephan Wienczny Assignee: Thomas Chojecki Priority: Trivial Fix For: 2.0.0 All resources shoud implement the java.io.closable interface (http://docs.oracle.com/javase/7/docs/api/java/io/Closeable.html) which is available since Java 1.5. I found this when looking at org.apache.pdfbox.pdmodel.PDDocument the close method already has the same signature it should have. Just the interface is missing. Once the interface is implemented you can use the new try-with-resource added to Java 1.7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1613) The ability to inject the time/random component into the COSWriter process to write a PDF document allows some advanced signature creation scenarios where the signature
[
https://issues.apache.org/jira/browse/PDFBOX-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki resolved PDFBOX-1613.
-
Resolution: Fixed
The ability to inject the time/random component into the COSWriter process to
write a PDF document allows some advanced signature creation scenarios where
the signature is generated on a separate server that does not hold the full
PDF document.
Key: PDFBOX-1613
URL: https://issues.apache.org/jira/browse/PDFBOX-1613
Project: PDFBox
Issue Type: Improvement
Components: Writing
Affects Versions: 1.8.1
Environment: Any
Reporter: Stefan Santesson
Assignee: Thomas Chojecki
Priority: Minor
Labels: security
Fix For: 2.0.0
I have developed a prototype server based signing service for the Swedish
National eID infrastructure.
I'll skip the details, but I recently switched to PDFBox for the PDF signing
process and it works great. However, I had to modify the COSWriter class to
get this working.
I'm writing to check whether you would consider adding the functionality I
need to future version of PDFBox.
The problem is the the signature service is just producing the signature, it
is not trusted to handle the PDF document.
The government service having the PDF document signed is using PDFBox in a 2
step process.
1) To produce the SignedAttributes DER Object of the CMS signature to be
created. This is the part that is hashed and signed by the signature service.
2) After receiving the signature and signature certs from the signature
service, completing the PDF signature by delivering the complete PKCS#7
object to PDFBox using the externally generated signature value and certs.
There are probably a more pure way to handle this, but Since PDFBox allows me
to create a signature interface that produces the SignedData. I found it to
be the easiest way to run the signature process 2 times.
1st pass using dummy key and dummy certs. This only to obtain the
SignedAttributes.
2nd pass by delivering a SignedData object that include the Signature value
and certs produced by the signature service.
Now in order to do this, I have to control the random seed added by the
COSWriter, or else the signature created by the signature service will not
match the hash in the SignedAttributes produced in the second pass.
My modification is provided below.
I simply provided an extra input parameter to the write function where I can
provide the long seed
I then added a backwards compatible write function where the long seed is
current time.
By providing the same seed to pass 1 and pass 2, I can get the externally
created signature to match the SignedAttributes produced in the first pass.
The write function below is identical to the original COSWriter function
except that it takes the idTime value from the function input parameter
instead of getting it from System.currentTimeMillis().
Modified functions of COSWriter:
/**
* This will write the pdf document.
*
* @param doc The document to write.
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc) throws COSVisitorException {
write(doc, System.currentTimeMillis());
}
/**
* This will write the pdf document.
*
* @param doc The document to write.
* @param idTime The time seed used to generate the id
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc, long idTime) throws COSVisitorException {
document = doc;
if (incrementalUpdate) {
prepareIncrement(doc);
}
// if the document says we should remove encryption, then we shouldn't
encrypt
if (doc.isAllSecurityToBeRemoved()) {
this.willEncrypt = false;
// also need to get rid of the Encrypt in the trailer so readers
// don't try to decrypt a document which is not encrypted
COSDocument cosDoc = doc.getDocument();
COSDictionary trailer = cosDoc.getTrailer();
trailer.removeItem(COSName.ENCRYPT);
} else {
SecurityHandler securityHandler = document.getSecurityHandler();
if (securityHandler != null) {
try {
securityHandler.prepareDocumentForEncryption(document);
this.willEncrypt = true;
} catch (IOException e) {
throw new COSVisitorException(e);
} catch
[jira] [Assigned] (PDFBOX-1613) The ability to inject the time/random component into the COSWriter process to write a PDF document allows some advanced signature creation scenarios where the signature
[
https://issues.apache.org/jira/browse/PDFBOX-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Chojecki reassigned PDFBOX-1613:
---
Assignee: Thomas Chojecki
The ability to inject the time/random component into the COSWriter process to
write a PDF document allows some advanced signature creation scenarios where
the signature is generated on a separate server that does not hold the full
PDF document.
Key: PDFBOX-1613
URL: https://issues.apache.org/jira/browse/PDFBOX-1613
Project: PDFBox
Issue Type: Improvement
Components: Writing
Affects Versions: 1.8.1
Environment: Any
Reporter: Stefan Santesson
Assignee: Thomas Chojecki
Priority: Minor
Labels: security
Fix For: 1.8.1
Original Estimate: 1h
Remaining Estimate: 1h
I have developed a prototype server based signing service for the Swedish
National eID infrastructure.
I'll skip the details, but I recently switched to PDFBox for the PDF signing
process and it works great. However, I had to modify the COSWriter class to
get this working.
I'm writing to check whether you would consider adding the functionality I
need to future version of PDFBox.
The problem is the the signature service is just producing the signature, it
is not trusted to handle the PDF document.
The government service having the PDF document signed is using PDFBox in a 2
step process.
1) To produce the SignedAttributes DER Object of the CMS signature to be
created. This is the part that is hashed and signed by the signature service.
2) After receiving the signature and signature certs from the signature
service, completing the PDF signature by delivering the complete PKCS#7
object to PDFBox using the externally generated signature value and certs.
There are probably a more pure way to handle this, but Since PDFBox allows me
to create a signature interface that produces the SignedData. I found it to
be the easiest way to run the signature process 2 times.
1st pass using dummy key and dummy certs. This only to obtain the
SignedAttributes.
2nd pass by delivering a SignedData object that include the Signature value
and certs produced by the signature service.
Now in order to do this, I have to control the random seed added by the
COSWriter, or else the signature created by the signature service will not
match the hash in the SignedAttributes produced in the second pass.
My modification is provided below.
I simply provided an extra input parameter to the write function where I can
provide the long seed
I then added a backwards compatible write function where the long seed is
current time.
By providing the same seed to pass 1 and pass 2, I can get the externally
created signature to match the SignedAttributes produced in the first pass.
The write function below is identical to the original COSWriter function
except that it takes the idTime value from the function input parameter
instead of getting it from System.currentTimeMillis().
Modified functions of COSWriter:
/**
* This will write the pdf document.
*
* @param doc The document to write.
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc) throws COSVisitorException {
write(doc, System.currentTimeMillis());
}
/**
* This will write the pdf document.
*
* @param doc The document to write.
* @param idTime The time seed used to generate the id
*
* @throws COSVisitorException If an error occurs while generating the data.
*/
public void write(PDDocument doc, long idTime) throws COSVisitorException {
document = doc;
if (incrementalUpdate) {
prepareIncrement(doc);
}
// if the document says we should remove encryption, then we shouldn't
encrypt
if (doc.isAllSecurityToBeRemoved()) {
this.willEncrypt = false;
// also need to get rid of the Encrypt in the trailer so readers
// don't try to decrypt a document which is not encrypted
COSDocument cosDoc = doc.getDocument();
COSDictionary trailer = cosDoc.getTrailer();
trailer.removeItem(COSName.ENCRYPT);
} else {
SecurityHandler securityHandler = document.getSecurityHandler();
if (securityHandler != null) {
try {
securityHandler.prepareDocumentForEncryption(document);
this.willEncrypt = true;
} catch (IOException e) {
[jira] [Created] (PDFBOX-1593) Adobe encrypted document doesn't parse correct (Adobe 5 and above compatibility)
Thomas Chojecki created PDFBOX-1593: --- Summary: Adobe encrypted document doesn't parse correct (Adobe 5 and above compatibility) Key: PDFBOX-1593 URL: https://issues.apache.org/jira/browse/PDFBOX-1593 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 1.8.1 Reporter: Thomas Chojecki Trying to parse and receive some information from encrypted documents created with Adobe 9 with compatibility to Acrobat 9, cause an error while decrypting informations. I tested documents with follow compatibility: Acrobat 3 (40-bit RC4) - works Acrobat 5 6 (128-bit RC4) - work Acrobat 7 (128-bit AES) - work Acrobat 9 (256-bit AES) - doesn't work The follow error will be thrown. Exception in thread main java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeEncryptedKey(StandardSecurityHandler.java:591) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeUserPassword(StandardSecurityHandler.java:628) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.isUserPassword(StandardSecurityHandler.java:812) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.prepareForDecryption(StandardSecurityHandler.java:213) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:154) at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1509) at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:919) at de.bos_bremen.pdftoolbox.testing.Test.main(Test.java:45) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1593) Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility)
[ https://issues.apache.org/jira/browse/PDFBOX-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1593: Summary: Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility) (was: Adobe encrypted document doesn't parse correct (Adobe 5 and above compatibility)) Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility) Key: PDFBOX-1593 URL: https://issues.apache.org/jira/browse/PDFBOX-1593 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 1.8.1 Reporter: Thomas Chojecki Trying to parse and receive some information from encrypted documents created with Adobe 9 with compatibility to Acrobat 9, cause an error while decrypting informations. I tested documents with follow compatibility: Acrobat 3 (40-bit RC4) - works Acrobat 5 6 (128-bit RC4) - work Acrobat 7 (128-bit AES) - work Acrobat 9 (256-bit AES) - doesn't work The follow error will be thrown. Exception in thread main java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeEncryptedKey(StandardSecurityHandler.java:591) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeUserPassword(StandardSecurityHandler.java:628) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.isUserPassword(StandardSecurityHandler.java:812) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.prepareForDecryption(StandardSecurityHandler.java:213) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:154) at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1509) at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:919) at de.bos_bremen.pdftoolbox.testing.Test.main(Test.java:45) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1593) Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility)
[ https://issues.apache.org/jira/browse/PDFBOX-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1593: Attachment: Test.pdf Test_secured Adobe7_compatible.pdf Test_secured Adobe9.pdf Test_secured Adobe9 doesn't work Test_secured Adobe7 work and the original unencrypted document Test Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility) Key: PDFBOX-1593 URL: https://issues.apache.org/jira/browse/PDFBOX-1593 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 1.8.1 Reporter: Thomas Chojecki Attachments: Test.pdf, Test_secured Adobe7_compatible.pdf, Test_secured Adobe9.pdf Trying to parse and receive some information from encrypted documents created with Adobe 9 with compatibility to Acrobat 9, cause an error while decrypting informations. I tested documents with follow compatibility: Acrobat 3 (40-bit RC4) - works Acrobat 5 6 (128-bit RC4) - work Acrobat 7 (128-bit AES) - work Acrobat 9 (256-bit AES) - doesn't work The follow error will be thrown. Exception in thread main java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeEncryptedKey(StandardSecurityHandler.java:591) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeUserPassword(StandardSecurityHandler.java:628) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.isUserPassword(StandardSecurityHandler.java:812) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.prepareForDecryption(StandardSecurityHandler.java:213) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:154) at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1509) at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:919) at de.bos_bremen.pdftoolbox.testing.Test.main(Test.java:45) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PDFBOX-1593) Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility)
[ https://issues.apache.org/jira/browse/PDFBOX-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki closed PDFBOX-1593. --- Resolution: Duplicate Assignee: Thomas Chojecki yes, the same issue. Didn't notice this one. Thx Adobe encrypted document doesn't parse correct (Acrobat 9 compatibility) Key: PDFBOX-1593 URL: https://issues.apache.org/jira/browse/PDFBOX-1593 Project: PDFBox Issue Type: Bug Components: Parsing Affects Versions: 1.8.1 Reporter: Thomas Chojecki Assignee: Thomas Chojecki Attachments: Test.pdf, Test_secured Adobe7_compatible.pdf, Test_secured Adobe9.pdf Trying to parse and receive some information from encrypted documents created with Adobe 9 with compatibility to Acrobat 9, cause an error while decrypting informations. I tested documents with follow compatibility: Acrobat 3 (40-bit RC4) - works Acrobat 5 6 (128-bit RC4) - work Acrobat 7 (128-bit AES) - work Acrobat 9 (256-bit AES) - doesn't work The follow error will be thrown. Exception in thread main java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeEncryptedKey(StandardSecurityHandler.java:591) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.computeUserPassword(StandardSecurityHandler.java:628) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.isUserPassword(StandardSecurityHandler.java:812) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.prepareForDecryption(StandardSecurityHandler.java:213) at org.apache.pdfbox.pdmodel.encryption.StandardSecurityHandler.decryptDocument(StandardSecurityHandler.java:154) at org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1509) at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:919) at de.bos_bremen.pdftoolbox.testing.Test.main(Test.java:45) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1336) JVM Crashes on Linux OS + Sun JVM + PDFBox
[ https://issues.apache.org/jira/browse/PDFBOX-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13647390#comment-13647390 ] Thomas Chojecki commented on PDFBOX-1336: - I checked the provided jar file with a decompiler and you are right. I commented it out to test it and forget to undo my changes before building. I have uploaded an up to date jar, after a check it has the needed line. http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT_fix.jar So if someone can confirm that this work, I would close both issues. JVM Crashes on Linux OS + Sun JVM + PDFBox -- Key: PDFBOX-1336 URL: https://issues.apache.org/jira/browse/PDFBOX-1336 Project: PDFBox Issue Type: Bug Affects Versions: 1.7.0 Environment: CentOS 5.6 Sun JVM Java version: 6 update 31 Tomcat 7.0.26 Reporter: Ann Addicks Priority: Critical Attachments: CrashTest.java, hs_err_pid16603.log, pdfcrowd_1334685364.pdf A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x796af64d, pid=16603, tid=2021653392 # # JRE version: 6.0_31-b04 # Java VM: Java HotSpot(TM) Server VM (20.6-b01 mixed mode linux-x86 ) # Problematic frame: # C [libfontmanager.so+0x1e64d] imaginary long double+0x7d # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. I can provide the full error, please let me know. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1587) Update the dependency on Bouncy Castle to 1.48
[ https://issues.apache.org/jira/browse/PDFBOX-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645714#comment-13645714 ] Thomas Chojecki commented on PDFBOX-1587: - Hi, thx for providing this improvement. The interface changes that comes with BouncyCastle will break old implementations. Each application that try to parse encrypted documents and using bouncy castle for his own software, wouldn't work any more. So I think this would be an improvement for the 2.0.0 release of the pdfbox. Update the dependency on Bouncy Castle to 1.48 --- Key: PDFBOX-1587 URL: https://issues.apache.org/jira/browse/PDFBOX-1587 Project: PDFBox Issue Type: Improvement Affects Versions: 1.8.1 Reporter: Emmanuel Bourg Attachments: pdfbox-bouncycastle-update.patch The recent versions of Bouncy Castle didn't preserve the binary compatibility and PDFBox doesn't compile against them. This is an issue for the Debian project because the Bouncy Castle package has to be updated to 1.48 in order to fix a security issue. This update is going to break the PDFBox package. Could you please update the dependency on Bouncy Castle? I'll attach the patch with the necessary changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1587) Update the dependency on Bouncy Castle to 1.48
[ https://issues.apache.org/jira/browse/PDFBOX-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki updated PDFBOX-1587: Fix Version/s: 2.0.0 Assignee: Thomas Chojecki Update the dependency on Bouncy Castle to 1.48 --- Key: PDFBOX-1587 URL: https://issues.apache.org/jira/browse/PDFBOX-1587 Project: PDFBox Issue Type: Improvement Affects Versions: 1.8.1 Reporter: Emmanuel Bourg Assignee: Thomas Chojecki Fix For: 2.0.0 Attachments: pdfbox-bouncycastle-update.patch The recent versions of Bouncy Castle didn't preserve the binary compatibility and PDFBox doesn't compile against them. This is an issue for the Debian project because the Bouncy Castle package has to be updated to 1.48 in order to fix a security issue. This update is going to break the PDFBox package. Could you please update the dependency on Bouncy Castle? I'll attach the patch with the necessary changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1587) Update the dependency on Bouncy Castle to 1.48
[ https://issues.apache.org/jira/browse/PDFBOX-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645768#comment-13645768 ] Thomas Chojecki commented on PDFBOX-1587: - For example: 1) If an project use the pdfbox and do some cryptographics and stay at bc 1.46 with this acutal pdfbox, no problem will occure. - OK 2) If the dependency would be updated to 1.48, the code of the project will break without update to the new classes. - ERROR 3) If the project that using pdfbox try to force the bc 1.46 version, pdfbox will break while parsing encrypted documents trying to access not available objects. - ERROR Update the dependency on Bouncy Castle to 1.48 --- Key: PDFBOX-1587 URL: https://issues.apache.org/jira/browse/PDFBOX-1587 Project: PDFBox Issue Type: Improvement Affects Versions: 1.8.1 Reporter: Emmanuel Bourg Assignee: Thomas Chojecki Fix For: 2.0.0 Attachments: pdfbox-bouncycastle-update.patch The recent versions of Bouncy Castle didn't preserve the binary compatibility and PDFBox doesn't compile against them. This is an issue for the Debian project because the Bouncy Castle package has to be updated to 1.48 in order to fix a security issue. This update is going to break the PDFBox package. Could you please update the dependency on Bouncy Castle? I'll attach the patch with the necessary changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1587) Update the dependency on Bouncy Castle to 1.48
[ https://issues.apache.org/jira/browse/PDFBOX-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1587. - Resolution: Fixed fixed in rev 147 the trunk is going 2.0.0, so there should be no problem. Update the dependency on Bouncy Castle to 1.48 --- Key: PDFBOX-1587 URL: https://issues.apache.org/jira/browse/PDFBOX-1587 Project: PDFBox Issue Type: Improvement Affects Versions: 1.8.1 Reporter: Emmanuel Bourg Assignee: Thomas Chojecki Fix For: 2.0.0 Attachments: pdfbox-bouncycastle-update.patch The recent versions of Bouncy Castle didn't preserve the binary compatibility and PDFBox doesn't compile against them. This is an issue for the Debian project because the Bouncy Castle package has to be updated to 1.48 in order to fix a security issue. This update is going to break the PDFBox package. Could you please update the dependency on Bouncy Castle? I'll attach the patch with the necessary changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1580) Oracle JVM crashes because of embedded fonts.
[ https://issues.apache.org/jira/browse/PDFBOX-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645853#comment-13645853 ] Thomas Chojecki commented on PDFBOX-1580: - thanks for contributing this patch. I've tried to look at this bug reports but there seem to be gone/removed. Did you have a test for this issue? So I could fix it asap. Oracle JVM crashes because of embedded fonts. - Key: PDFBOX-1580 URL: https://issues.apache.org/jira/browse/PDFBOX-1580 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.7.0, 1.7.1, 1.8.0, 1.8.1 Environment: Linux 64-bit Oracle JRE 6.0_45-b06 or 7.0_21-b11 Reporter: Christian Kohlschütter Priority: Blocker Labels: PatchAvailable, Regression Attachments: PDFBOX-1580.patch Oracle's closed-source font rendering chokes on some fonts embedded in PDFs because their cmap data is either missing or invalid. Using OpenJDK, no crashes were observed. The JVM crashes right after attempting to draw a glyph vector using codepoints, which is called from within PDSimpleFont#drawString. Versions of pdfbox prior to 1.7.0 did not crash. The crashes look like this: JRE 6: # JRE version: 6.0_45-b06 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libfontmanager.so+0x242c8] imaginary long double+0xd8 JRE 7: # JRE version: 7.0_21-b11 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libt2k.so+0x2e6b1] Compute_cmapClass_GlyphIndex+0x1 Since older versions of pdfbox did not crash, I tracked the problem down to a call to java.awt.Font#canDisplayUpTo(String) that has been moved in 1.7.0 from the top of PDSimpleFont#drawString down to a branch. Moving the call back up prevented the crash. It looks like a call to java.awt.Font#canDisplay(int) initializes some internal data structures of Oracle's fontmanager, preventing the JVM crash. As I have observed this crash only for fonts that have been processed through PDType0Font, I have added a fix there, which should save us some cycles and, more importantly, should not create new problems. Oracle bug reports have been filed for both JRE 6 and 7, including a minimal test case: Oracle JRE 6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9002077 Oracle JRE 7: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9002078 There have been a few other bug reports mentioning a similar crash on other platforms, older JRE versions, e.g.: PDFBOX-1426, PDFBOX-1336. The patch provided here might fix these bugs, too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PDFBOX-1580) Oracle JVM crashes because of embedded fonts.
[ https://issues.apache.org/jira/browse/PDFBOX-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Chojecki resolved PDFBOX-1580. - Resolution: Fixed Fix Version/s: 2.0.0 Assignee: Thomas Chojecki Fixed in rev. 1477806 Oracle JVM crashes because of embedded fonts. - Key: PDFBOX-1580 URL: https://issues.apache.org/jira/browse/PDFBOX-1580 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.7.0, 1.7.1, 1.8.0, 1.8.1 Environment: Linux 64-bit Oracle JRE 6.0_45-b06 or 7.0_21-b11 Reporter: Christian Kohlschütter Assignee: Thomas Chojecki Priority: Blocker Labels: PatchAvailable, Regression Fix For: 2.0.0 Attachments: PDFBOX-1580.patch Oracle's closed-source font rendering chokes on some fonts embedded in PDFs because their cmap data is either missing or invalid. Using OpenJDK, no crashes were observed. The JVM crashes right after attempting to draw a glyph vector using codepoints, which is called from within PDSimpleFont#drawString. Versions of pdfbox prior to 1.7.0 did not crash. The crashes look like this: JRE 6: # JRE version: 6.0_45-b06 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libfontmanager.so+0x242c8] imaginary long double+0xd8 JRE 7: # JRE version: 7.0_21-b11 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libt2k.so+0x2e6b1] Compute_cmapClass_GlyphIndex+0x1 Since older versions of pdfbox did not crash, I tracked the problem down to a call to java.awt.Font#canDisplayUpTo(String) that has been moved in 1.7.0 from the top of PDSimpleFont#drawString down to a branch. Moving the call back up prevented the crash. It looks like a call to java.awt.Font#canDisplay(int) initializes some internal data structures of Oracle's fontmanager, preventing the JVM crash. As I have observed this crash only for fonts that have been processed through PDType0Font, I have added a fix there, which should save us some cycles and, more importantly, should not create new problems. Oracle bug reports have been filed for both JRE 6 and 7, including a minimal test case: Oracle JRE 6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9002077 Oracle JRE 7: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9002078 There have been a few other bug reports mentioning a similar crash on other platforms, older JRE versions, e.g.: PDFBOX-1426, PDFBOX-1336. The patch provided here might fix these bugs, too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1336) JVM Crashes on Linux OS + Sun JVM + PDFBox
[ https://issues.apache.org/jira/browse/PDFBOX-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13646004#comment-13646004 ] Thomas Chojecki commented on PDFBOX-1336: - This issue should be fixed with PDFBOX-1580. Thx to Christian Kohlschütter for the patch. Can not reproduce it. Can someone test it with the given snapshot? http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/fontbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/jempbox-2.0.0-SNAPSHOT.jar JVM Crashes on Linux OS + Sun JVM + PDFBox -- Key: PDFBOX-1336 URL: https://issues.apache.org/jira/browse/PDFBOX-1336 Project: PDFBox Issue Type: Bug Affects Versions: 1.7.0 Environment: CentOS 5.6 Sun JVM Java version: 6 update 31 Tomcat 7.0.26 Reporter: Ann Addicks Priority: Critical Attachments: hs_err_pid16603.log, pdfcrowd_1334685364.pdf A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x796af64d, pid=16603, tid=2021653392 # # JRE version: 6.0_31-b04 # Java VM: Java HotSpot(TM) Server VM (20.6-b01 mixed mode linux-x86 ) # Problematic frame: # C [libfontmanager.so+0x1e64d] imaginary long double+0x7d # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. I can provide the full error, please let me know. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1426) JVM crashes when trying to process the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13646003#comment-13646003 ] Thomas Chojecki commented on PDFBOX-1426: - This issue should be fixed with PDFBOX-1580. Thx to Christian Kohlschütter for the patch. Can not reproduce it. Can someone test it with the given snapshot? http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/fontbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/jempbox-2.0.0-SNAPSHOT.jar JVM crashes when trying to process the attached pdf's - Key: PDFBOX-1426 URL: https://issues.apache.org/jira/browse/PDFBOX-1426 Project: PDFBox Issue Type: Bug Affects Versions: 1.7.1 Environment: OS: Windows Server 2003 family Build 3790 Service Pack 2 Reporter: Alejandro Cerdas Priority: Critical Labels: patch Attachments: Delta Ticket.pdf, MERX Subscription Fee - Final.pdf # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d703bf9, pid=5384, tid=4788 # # JRE version: 6.0_18-b07 # Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode windows-x86 ) # Problematic frame: # C [fontmanager.dll+0x13bf9] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x6a057400): JavaThread ajp-127.0.0.1-8009-11 daemon [_thread_in_native, id=4788, stack(0x6cf1,0x6cf6)] siginfo: ExceptionCode=0xc005, reading address 0x0010 Registers: EAX=0x, EBX=0x, ECX=0x000a, EDX=0x69b1c6c8 ESP=0x6cf5e89c, EBP=0x6cf5e8b4, ESI=0x6aadfdd0, EDI=0x6aadfdd0 EIP=0x6d703bf9, EFLAGS=0x00010246 Top of Stack: (sp=0x6cf5e89c) 0x6cf5e89c: 6aadfdd0 636d6170 6aadfdd0 0x6cf5e8ac: 6d703d33 685e4130 6cf5e924 6d6f3ced 0x6cf5e8bc: 6aadfdd0 0062 6cf5e920 0x6cf5e8cc: 6aadfdd0 685e4130 0001 0x6cf5e8dc: 0007 0x6cf5e8ec: 6a8a3840 0x6cf5e8fc: 6a8a3c98 0x6cf5e90c: 6a8a3838 Instructions: (pc=0x6d703bf9) 0x6d703be9: 75 51 57 68 70 61 6d 63 56 e8 6f fd ff ff 6a 00 0x6d703bf9: ff 70 10 ff 70 0c ff b6 88 00 00 00 ff b6 90 00 Stack: [0x6cf1,0x6cf6], sp=0x6cf5e89c, free space=13a6cf5e3d8k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [fontmanager.dll+0x13bf9] C [fontmanager.dll+0x3ced] C [fontmanager.dll+0x3da3] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j sun.font.FileFont.getGlyphImage(JI)J+0 J sun.font.FileFontStrike.getGlyphMetrics(IZ)Ljava/awt/geom/Point2D$Float; J sun.font.FileFontStrike.getGlyphMetrics(I)Ljava/awt/geom/Point2D$Float; J sun.font.StandardGlyphVector.initPositions()V J sun.font.GlyphList.setFromGlyphVector(Lsun/java2d/loops/FontInfo;Ljava/awt/font/GlyphVector;FF)V J sun.java2d.pipe.GlyphListPipe.drawGlyphVector(Lsun/java2d/SunGraphics2D;Ljava/awt/font/GlyphVector;FF)V j sun.java2d.pipe.ValidatePipe.drawGlyphVector(Lsun/java2d/SunGraphics2D;Ljava/awt/font/GlyphVector;FF)V+17 J sun.java2d.SunGraphics2D.drawGlyphVector(Ljava/awt/font/GlyphVector;FF)V j org.apache.pdfbox.pdmodel.font.PDSimpleFont.writeFont(Ljava/awt/Graphics2D;Ljava/awt/geom/AffineTransform;FFLjava/awt/font/GlyphVector;)V+63 j org.apache.pdfbox.pdmodel.font.PDSimpleFont.drawString(Ljava/lang/String;[ILjava/awt/Graphics;FLjava/awt/geom/AffineTransform;FF)V+253 j org.apache.pdfbox.pdfviewer.PageDrawer.processTextPosition(Lorg/apache/pdfbox/util/TextPosition;)V+436 J org.apache.pdfbox.util.PDFStreamEngine.processEncodedText([B)V J org.apache.pdfbox.util.operator.ShowTextGlyph.process(Lorg/apache/pdfbox/util/PDFOperator;Ljava/util/List;)V J org.apache.pdfbox.util.PDFStreamEngine.processSubStream(Lorg/apache/pdfbox/cos/COSStream;)V j org.apache.pdfbox.util.PDFStreamEngine.processSubStream(Lorg/apache/pdfbox/pdmodel/PDPage;Lorg/apache/pdfbox/pdmodel/PDResources;Lorg/apache/pdfbox/cos/COSStream;)V+20 j org.apache.pdfbox.util.PDFStreamEngine.processStream(Lorg/apache/pdfbox/pdmodel/PDPage;Lorg/apache/pdfbox/pdmodel/PDResources;Lorg/apache/pdfbox/cos/COSStream;)V+43 j org.apache.pdfbox.pdfviewer.PageDrawer.drawPage(Ljava/awt/Graphics;Lorg/apache/pdfbox/pdmodel/PDPage;Ljava/awt/Dimension;)V+80 j org.apache.pdfbox.pdmodel.PDPage.convertToImage(II)Ljava/awt/image/BufferedImage;+200 j
[jira] [Commented] (PDFBOX-1560) Migrate the PDFBox website to the ASF CMS
[ https://issues.apache.org/jira/browse/PDFBOX-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638867#comment-13638867 ] Thomas Chojecki commented on PDFBOX-1560: - @Maruan the page looks great :-) thx for the work I uploaded the to http://people.apache.org/~tchojecki/pdfbox_demo/ the links you are using looking absolute. I started to link it relative but this will take some time :-) index is up but the other references aren't. to fix it, only the leading / need to be removed for links and resources. Migrate the PDFBox website to the ASF CMS - Key: PDFBOX-1560 URL: https://issues.apache.org/jira/browse/PDFBOX-1560 Project: PDFBox Issue Type: Task Reporter: Maruan Sahyoun Assignee: Maruan Sahyoun Priority: Minor Attachments: cmssite-cookbook.png, cmssite-home.png, pdfbox_logo_001.pdf, pdfbox_logo_002.svg, pdfbox_logo_003.pdf, pdfbox-site.zip Issue to track the migration of the PDFBox website to the ASF CMS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
