[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208275#comment-17208275 ] ASF subversion and git services commented on PDFBOX-4421: - Commit 1882256 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1882256 ] PDFBOX-4421: improve exception text > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208276#comment-17208276 ] ASF subversion and git services commented on PDFBOX-4421: - Commit 1882257 from Tilman Hausherr in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1882257 ] PDFBOX-4421: improve exception text > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4979) Using Mirth with PDFBox 2.0.21 and unable to call method getPages()
Dayne Foresman created PDFBOX-4979: -- Summary: Using Mirth with PDFBox 2.0.21 and unable to call method getPages() Key: PDFBOX-4979 URL: https://issues.apache.org/jira/browse/PDFBOX-4979 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 2.0.21 Reporter: Dayne Foresman I am using javascript within Mirth and have imported the needed libraries. Tried calling from PDDocument and from PDPageTree; both return errors when trying to call getPages(). 141: var pages = new Packages.org.apache.pdfbox.pdmodel.PDDocument.getPages(); 142: /* 143: //Creating an iterator 144: //var iterator = Pages.listIterator(); 145: var iterator = new org.apache.pdfbox.pdmodel.PDPageTree.iterator(); LINE NUMBER: 141 DETAILS: Java class "org.apache.pdfbox.pdmodel.PDDocument" has no public instance field or method named "getPages". at 0d3bfc86-b3d5-4c6b-97f2-384354459b54:141 (doTransform) at 0d3bfc86-b3d5-4c6b-97f2-384354459b54:177 (doScript) at 0d3bfc86-b3d5-4c6b-97f2-384354459b54:179 at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.doCall(JavaS criptFilterTransformer.java:154) at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.doCall(JavaS criptFilterTransformer.java:119) at com.mirth.connect.server.util.javascript.JavaScrip tTask.call(JavaScriptTask.java:113) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker( Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208259#comment-17208259 ] Tilman Hausherr edited comment on PDFBOX-4421 at 10/5/20, 6:59 PM: --- Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. Also, keyStore parameter null is reported as "Provided decryption material is not compatible with the document" which is 臘♂️ was (Author: tilman): Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208259#comment-17208259 ] Tilman Hausherr commented on PDFBOX-4421: - Need to do some housekeeping, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208259#comment-17208259 ] Tilman Hausherr edited comment on PDFBOX-4421 at 10/5/20, 6:57 PM: --- Need to do some housekeeping before resolving, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. was (Author: tilman): Need to do some housekeeping, some of the commits are missing in this ticket. Maybe svn2jira was down (again) without me noticing. > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208256#comment-17208256 ] ASF subversion and git services commented on PDFBOX-4421: - Commit 1882255 from Tilman Hausherr in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1882255 ] PDFBOX-4421: adjust test to use the files provided by Christian Appl > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208222#comment-17208222 ] ASF subversion and git services commented on PDFBOX-4421: - Commit 1882254 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1882254 ] PDFBOX-4421: adjust test to use the files provided by Christian Appl > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4976) OperatorException Strict Mode
[ https://issues.apache.org/jira/browse/PDFBOX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208217#comment-17208217 ] Maruan Sahyoun commented on PDFBOX-4976: Introducing a strict mode can only be done gradually given the many workarounds put into PDFBox over the years. OTOH why not start with a specific area. Maybe instead of throwing an exception we can put the swallowed errors in a queue one could listen too. Little similar to throwing processing events in Apache FOP. > OperatorException Strict Mode > - > > Key: PDFBOX-4976 > URL: https://issues.apache.org/jira/browse/PDFBOX-4976 > Project: PDFBox > Issue Type: Improvement > Components: Rendering >Reporter: James Maguire >Priority: Minor > Attachments: > Strict_operatorException_mode_configurable_via_system_property.patch > > > When utilizing PDFBox in a security strict environment it can be useful to > enforce a stricter parsing mode. While this is not appropriate in all > contexts for some use cases - e.g. watermarked PDFs it is essential that the > PDF is rendered without errors. > > This patch offers the ability to configure a system property which will > always throw an exception when an operatorException is triggered > Patch attached -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[
https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208198#comment-17208198
]
Tilman Hausherr edited comment on PDFBOX-4297 at 10/5/20, 5:15 PM:
---
{code}
COSString contents = (COSString)
sig.getCOSObject().getDictionaryObject(COSName.CONTENTS);
byte [] ba = contents.getBytes();
{code}
But I guess you'd like a direct PDSignature method. I have no idea why the two
methods we are offering read the whole file.
was (Author: tilman):
{\{code}}
COSString contents = (COSString)
sig.getCOSObject().getDictionaryObject(COSName.CONTENTS);
byte [] ba = contents.getBytes();
{\{code}}
But I guess you'd like a direct PDSignature method. I have no idea why the two
methods we are offering read the whole file.
> Allow to space efficiently analyse large PDFs
> -
>
> Key: PDFBOX-4297
> URL: https://issues.apache.org/jira/browse/PDFBOX-4297
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing
>Reporter: Ralf Hauser
>Priority: Major
>
> Assume you get a 300+MB large pdf and need to know
> 1) the file names of embedded files if any
> 2) whether it is encrypted (symmetric or asymmetric)
> 3) certification level (and whether it is signed)
> This should not use more than 5 MB (extra) memory
>
> P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle
> large PDF files"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[
https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208198#comment-17208198
]
Tilman Hausherr commented on PDFBOX-4297:
-
{\{code}}
COSString contents = (COSString)
sig.getCOSObject().getDictionaryObject(COSName.CONTENTS);
byte [] ba = contents.getBytes();
{\{code}}
But I guess you'd like a direct PDSignature method. I have no idea why the two
methods we are offering read the whole file.
> Allow to space efficiently analyse large PDFs
> -
>
> Key: PDFBOX-4297
> URL: https://issues.apache.org/jira/browse/PDFBOX-4297
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing
>Reporter: Ralf Hauser
>Priority: Major
>
> Assume you get a 300+MB large pdf and need to know
> 1) the file names of embedded files if any
> 2) whether it is encrypted (symmetric or asymmetric)
> 3) certification level (and whether it is signed)
> This should not use more than 5 MB (extra) memory
>
> P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle
> large PDF files"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4976) OperatorException Strict Mode
[ https://issues.apache.org/jira/browse/PDFBOX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208197#comment-17208197 ] Tilman Hausherr commented on PDFBOX-4976: - There are hundreds, if not thousands of (fixed) "bugs" where a PDF is not specification compliant and users insist "but it renders on Adobe Viewer". So your patch would "strict" only one tiny segment of parsing / rendering. The alternative is that you use JHOVE, or VeraPDF if your files are PDF/A. (We have also a PDF/A-1b checker, but it isn't as good as the one from VeraPDF) > OperatorException Strict Mode > - > > Key: PDFBOX-4976 > URL: https://issues.apache.org/jira/browse/PDFBOX-4976 > Project: PDFBox > Issue Type: Improvement > Components: Rendering >Reporter: James Maguire >Priority: Minor > Attachments: > Strict_operatorException_mode_configurable_via_system_property.patch > > > When utilizing PDFBox in a security strict environment it can be useful to > enforce a stricter parsing mode. While this is not appropriate in all > contexts for some use cases - e.g. watermarked PDFs it is essential that the > PDF is rendered without errors. > > This patch offers the ability to configure a system property which will > always throw an exception when an operatorException is triggered > Patch attached -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3330) Enhance and update PDFBox website & documentation
[ https://issues.apache.org/jira/browse/PDFBOX-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208179#comment-17208179 ] ASF subversion and git services commented on PDFBOX-3330: - Commit 74b75b4a73f9e5527d87f8a02262793f17ea754b in pdfbox-docs's branch refs/heads/master from Maruan Sahyoun [ https://gitbox.apache.org/repos/asf?p=pdfbox-docs.git;h=74b75b4 ] PDFBOX-3330: update pdfbox version in getting started page > Enhance and update PDFBox website & documentation > - > > Key: PDFBOX-3330 > URL: https://issues.apache.org/jira/browse/PDFBOX-3330 > Project: PDFBox > Issue Type: Task > Components: Documentation >Reporter: Maruan Sahyoun >Priority: Major > Attachments: Bildschirmfoto von »2018-03-14 22-59-10«.png, > Bildschirmfoto von »2018-03-14 22-59-21«.png, PDFBox.Logo-0.1.0.png, > pdfbox-topbar.pdf, screenshot-1.png, toolbox.svg, topbar.png > > > General purpose ticket to track enhancements to the website and documentation -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4978) Include maven coordinates in downloads page
[ https://issues.apache.org/jira/browse/PDFBOX-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208170#comment-17208170 ] Maruan Sahyoun commented on PDFBOX-4978: https://pdfbox.apache.org/2.0/getting-started.html provides the info what to include for maven. Is that sufficient? > Include maven coordinates in downloads page > --- > > Key: PDFBOX-4978 > URL: https://issues.apache.org/jira/browse/PDFBOX-4978 > Project: PDFBox > Issue Type: Bug > Components: Documentation >Reporter: Mantas Gridinas >Priority: Minor > > After looking through the current pages of PDFBox I see that the download > page only includes the ZIP packages binaries, which are hard to use in end > product, and even harder to share across multiple people. Provide maven > coordinates for your binaries in the same download pages. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4978) Include maven coordinates in downloads page
Mantas Gridinas created PDFBOX-4978: --- Summary: Include maven coordinates in downloads page Key: PDFBOX-4978 URL: https://issues.apache.org/jira/browse/PDFBOX-4978 Project: PDFBox Issue Type: Bug Components: Documentation Reporter: Mantas Gridinas After looking through the current pages of PDFBox I see that the download page only includes the ZIP packages binaries, which are hard to use in end product, and even harder to share across multiple people. Provide maven coordinates for your binaries in the same download pages. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4976) OperatorException Strict Mode
[ https://issues.apache.org/jira/browse/PDFBOX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208018#comment-17208018 ] Michael Klink commented on PDFBOX-4976: --- While I would also prefer a more strict (at least optionally so) parsing, I don't think that your patch by itself makes sense because it only signals specific problems while others are swallowed by PDFBox without such exceptions. A more holistic approach would require analyzing all operator processors for explicitly and implicitly ignored errors and establishing an error messaging mechanism that allows to continue content stream processing, too. But this of course would require much more time to do. > OperatorException Strict Mode > - > > Key: PDFBOX-4976 > URL: https://issues.apache.org/jira/browse/PDFBOX-4976 > Project: PDFBox > Issue Type: Improvement > Components: Rendering >Reporter: James Maguire >Priority: Minor > Attachments: > Strict_operatorException_mode_configurable_via_system_property.patch > > > When utilizing PDFBox in a security strict environment it can be useful to > enforce a stricter parsing mode. While this is not appropriate in all > contexts for some use cases - e.g. watermarked PDFs it is essential that the > PDF is rendered without errors. > > This patch offers the ability to configure a system property which will > always throw an exception when an operatorException is triggered > Patch attached -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4970) Possibility to detect duplicate ids in a revision
[
https://issues.apache.org/jira/browse/PDFBOX-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207987#comment-17207987
]
Michael Klink commented on PDFBOX-4970:
---
It would indeed be nice to have the PDF Debugger extended to provide
information on changes between revisions and on unused material in the PDF. Or
even better, to have these information available via members of the
{{PDDocument}}.
Beware, though:
{quote}we would like to be able to detect that kind of prepared documents for
the given attack. We were thinking to check if any duplicate object id is
present in the document to be signed.
{quote}
Only because there is a duplicate object number in a revision, you cannot be
sure yet that the document is _prepared for a shadow attack_, it merely has the
_stink_ of such an attack.
I played around a bit myself, and my sniffer routine found a number of false
positives, in particular:
* Some PDF processors write data to the PDF output stream early to save
memory. If the objects in question are changed again later in the same run, a
second, updated copy of the object is simply appended to the stream to be later
referenced from the cross references instead of the earlier version. As here
there are two objects with similar but not identical contents in the same
revision, one could falsely assume an attack preparation.
* If the PDF in question contains an embedded PDF attachment, there quite
likely are numerous object numbers used both in the embedded and in the
embedding PDF. Embedding PDF attachments like that _can_ be a preparation for a
shadow attack but usually isn't one.
Similarly, sniffing for the other attack types also only finds _stinks_ of such
_preparations_ but not 100% sure indications. E.g. non-matching form field
values and display values also occur for other, dumb reasons, unrelated to
attacks.
Thus, you most likely won't _be able to detect that kind of prepared documents
for the given attack_, merely a _stink_ thereof.
Nonetheless, also detection of a mere stink can be interesting as an attacker
can probably exploit such accidental existing structures like an attack
preparation. The result might be subtle changes, e.g. a switch to a previous
revision of some paragraph in a contract which for good reasons has not been
signed in that original form.
> Possibility to detect duplicate ids in a revision
> -
>
> Key: PDFBOX-4970
> URL: https://issues.apache.org/jira/browse/PDFBOX-4970
> Project: PDFBox
> Issue Type: Improvement
>Reporter: Pierrick Vandenbroucke
>Priority: Major
>
> We are trying to detect files which contain several objects with the same
> identifier within a revision or in a given PDF. Currently, that seems not
> possible. We are facing to this
> [map|https://github.com/apache/pdfbox/blob/2.0.21/pdfbox/src/main/java/org/apache/pdfbox/cos/COSDocument.java#L56]
> which only allows one instance by object id. The map usage brings
> limitations (eg : rendering,...).
> Is that possible to detect such files ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4962) CMYK support
[
https://issues.apache.org/jira/browse/PDFBOX-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207918#comment-17207918
]
Simon Steiner commented on PDFBOX-4962:
---
new Color(CMYKColorSpace, color.getComponents(), 1);
seems to break the color caching and so its really slow
> CMYK support
>
>
> Key: PDFBOX-4962
> URL: https://issues.apache.org/jira/browse/PDFBOX-4962
> Project: PDFBox
> Issue Type: Bug
>Reporter: Simon Steiner
>Priority: Major
> Attachments: pdfbox2cmyk.patch, pdfcolor.patch
>
>
> If the content stream has a cmyk color:
> 0 0 0 1 k
> pdfbox will convert this to rgb causing loss of fidelity
> is it possible to pass the cmyk color when you call graphics2d eg:
> {color:#660e7a}graphics{color}.setPaint(cmyk value)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207888#comment-17207888 ] Christian Appl edited comment on PDFBOX-4421 at 10/5/20, 8:06 AM: -- Sure! "AESkeylength128.pdf" and "AESkeylength256.pdf" should both be using certificates from the "keystore.pfx" I already shared. alias: testnutzer password: w!z%C*F-JaNdRgUk The used Software is the current Adobe Acrobat Pro DC if you want to check whether you can use those PDFs. was (Author: capsvd): Sure! "AESkeylength128.pdf" and "AESkeylength256.pdf" should both be using certificates from the "keystore.pfx" I already shared. alias: testnutzer password: w!z%C*F-JaNdRgUk > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Appl updated PDFBOX-4421: --- Attachment: AESkeylength256.pdf AESkeylength128.pdf > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: AESkeylength128.pdf, AESkeylength256.pdf, > B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4297) Allow to space efficiently analyse large PDFs
[ https://issues.apache.org/jira/browse/PDFBOX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207887#comment-17207887 ] Ralf Hauser commented on PDFBOX-4297: - 4) it would be great to obtain the PKCS7 signature-block (e.g. as byte-array) as return object > Allow to space efficiently analyse large PDFs > - > > Key: PDFBOX-4297 > URL: https://issues.apache.org/jira/browse/PDFBOX-4297 > Project: PDFBox > Issue Type: Improvement > Components: Parsing >Reporter: Ralf Hauser >Priority: Major > > Assume you get a 300+MB large pdf and need to know > 1) the file names of embedded files if any > 2) whether it is encrypted (symmetric or asymmetric) > 3) certification level (and whether it is signed) > This should not use more than 5 MB (extra) memory > > P.S.: seems to an exampe of https://pdfbox.apache.org/ideas.html "Handle > large PDF files" > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4421) Add support for AES128 encryption for public key
[ https://issues.apache.org/jira/browse/PDFBOX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207888#comment-17207888 ] Christian Appl commented on PDFBOX-4421: Sure! "AESkeylength128.pdf" and "AESkeylength256.pdf" should both be using certificates from the "keystore.pfx" I already shared. alias: testnutzer password: w!z%C*F-JaNdRgUk > Add support for AES128 encryption for public key > > > Key: PDFBOX-4421 > URL: https://issues.apache.org/jira/browse/PDFBOX-4421 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.13 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr >Priority: Major > Labels: AES128 > Fix For: 2.0.22, 3.0.0 PDFBox > > Attachments: B2-AES-256-secured.pdf, B2-Adobe-128-aes-sec.pdf, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(AES128,_256_-_filter_based_k.patch, > PDFBOX-4421_Add_support_for_AES128_encryption_for_public_key_(DRAFT).patch, > image-2020-09-16-10-32-11-060.png, image-2020-09-16-10-33-55-201.png, > image-2020-09-16-11-55-33-275.png, keystore.pfx, screenshot-1.png > > > Follow-up of PDFBOX-4413. AES256 works for public key crypto, but AES128 > doesn't when the file is generated by an external software. (local tests > work) We should at least get the decryption to work. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4928) Could the new rendering method of PageDrawer be optional?
[
https://issues.apache.org/jira/browse/PDFBOX-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207868#comment-17207868
]
Christian Appl commented on PDFBOX-4928:
Thanks for pushing the issue!
Well... good question...
{{setDownscalingImageOptimizationThreshhold()}}
{{setQualityImageDownscalingThreshhold()}}
{{setImageOptimizationThreshhold()}}
{{setQualityImageRenderingThreshhold()}}
I can't come up with a short one here either...
> Could the new rendering method of PageDrawer be optional?
> -
>
> Key: PDFBOX-4928
> URL: https://issues.apache.org/jira/browse/PDFBOX-4928
> Project: PDFBox
> Issue Type: Wish
> Components: Rendering
>Affects Versions: 2.0.20
>Reporter: Christian Appl
>Priority: Major
> Fix For: 2.0.22, 3.0.0 PDFBox
>
> Attachments: image-2020-08-03-09-43-37-412.png, prescaled.png,
> unprescaled.png
>
>
> This relates to {color:#008dde}PDFBOX-4516, PDFBOX-4527, PDFBOX-4815,
> PDFBOX-4886, PDFBOX-4863{color}{color:#008dde}
> I have tested the new prescaled rendering method for the
> {color}org.apache.pdfbox.rendering.{color:#008dde}PageDrawer
> {color:#172b4d}with PDFBox:2.0.21-SNAPSHOT{color}{color} for different
> images, with different resolutions, target image sizes etc. and compared the
> results to our old expectations (pre 2.0.20). And I really like it!
>
> However it seems to depend on the person's subjective perception (atleast
> for my tested images), whether I like the old or the new results better. When
> asking my colleagues, I heard arguments for both sides.
>
> Therefore my question is: Could a RenderingHint be introduced to
> disable/enable this separately and more intentionally, instead of assuming,
> that the scaling method must always be applied for specific scaling factors?
> This would allow users to select the scaling method according to their own
> liking and needs.
>
> I can not really find a crystal clear, objective answer, whether the one or
> the other is "better", therefore I would prefer being able to de/activate it
> according to my own judgement.
> As far as I understand, the criterion (scaleX < {color:#1750eb}0.5 {color}||
> {color:#00}scaleY {color}< {color:#1750eb}0.5{color}) has been selected
> rather arbitrarily.( ? )
> But what if I want to apply it even to images above those scaling factors?
> What if I want to not apply it to images bellow those scaling factors?
> What if I want to apply it to Image A, but not to Image C, for some unknown
> reason?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4963) TTF file leakage in font cache
[
https://issues.apache.org/jira/browse/PDFBOX-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17207856#comment-17207856
]
Maison commented on PDFBOX-4963:
Yes, the font cache holding Closeable objects in SoftReferences is a java
challenge... Unless fonts caching is refactored, I am afraid that using a
reference queue is the only way to go.
Note that when referent becomes unreachable and the rerefence is cleared, the
reference is somehow "guaranteed" to be added to the reference queue : this
occurs before finalization (which can be delayed).
Now, emptying this queue can be performed by the thread who calls getFont() or
addFont() : this is exactly what guava cache does when SoftReferences are used
: SoftReferences are created with a queue 'segment.valueReferenceQueue' here :
[https://github.com/google/guava/blob/master/guava/src/com/google/common/cache/LocalCache.java#L400]
and this queue is processed in drainValueReferenceQueue() :
[https://github.com/google/guava/blob/master/guava/src/com/google/common/cache/LocalCache.java#L2468]
The processing is performed at several steps : get(), if possible, and IIUC at
each write [see line 3427 : preWriteCleanup() calls runLockedCleanup()]
I couldn't find a way to use this ref queue pattern without a getter \{{
TrueTypeFont.getRAFStream()}}, which indeed slightly pollutes API.
> TTF file leakage in font cache
> --
>
> Key: PDFBOX-4963
> URL: https://issues.apache.org/jira/browse/PDFBOX-4963
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
>Affects Versions: 2.0.21
>Reporter: Maison
>Priority: Major
>
> We observe many TTF opened files in our production server, which result in
> exhausting file descriptors.
> We have checked and rechecked that every PDDocument is properly closed (try
> with resource everywhere).
> By looking at pdfbox source code, I suspect 2 problems in FontCache and in
> FileSystemFontProvider
> 1 - FontCache
> In FontCache, a map keeps SoftReference as values.
> IIUC for TTF fonts, the values are instances of
> org.apache.fontbox.ttf.TrueTypeFont. Such instances have a TTFDataStream
> member, which is RAFDataStream (so there is an opened file).
> Problem is that if the soft reference is cleared by GC, we can suppose the
> TrueTypeFont objects are GCed (is that guaranteed?) ; but what about the
> RAFDataStream sub-object ? There is no RAFDataStream.close() in TrueTypeFont
> finalizer
> 2 - FileSystemFontProvider
> There seems to be a TOCTOU-like race condition when a font is needed. Code
> looks like below (simplified) :
> @Override
> public FontBoxFont getFont()
>{
> FontBoxFont cached = parent.cache.getFont(this);
> if (cached != null) {
>return cached;
> }
> FontBoxFont font = ... // instantiate font
> parent.cache.addFont(this, font); // <--- not thread safe ?
> return font;
> }
> The font, if not in cache, is instantiated and added into cache. But two
> threads can do that at the same time, and the last addFont() wins. So the
> first SoftReference object is now eligible to GC; but the
> FontBoxFont has not been closed.
> This problem is probably less frequent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
