[jira] [Commented] (PDFBOX-3756) javax.crypto.BadPaddingException: Given final block not properly padded
[ https://issues.apache.org/jira/browse/PDFBOX-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998899#comment-15998899 ] Esteban Nicolas Ruiz commented on PDFBOX-3756: -- I have been doing some debugging, it seems that the exception happens while parsing this object (text copied from the PDF): 56 0 obj^M <>stream^M ^AÃ8ÆYòV®Ú¨<81, And this is the object referencing it (which is the catalog according to the already added "pdfdebugger.png"): 1 0 obj^M <><><>]/ON[ 100 0 R]/Order[]/RBGroups[]>>/OCGs[ 100 0 R]>>/Pages 3 0 R/Type/Catalog/AcroForm 136 0 R>>^M endobj^M Maybe PDFBOX is trying to decrypt the Metadata although decryption is not needed to "view" the PDF? > javax.crypto.BadPaddingException: Given final block not properly padded > --- > > Key: PDFBOX-3756 > URL: https://issues.apache.org/jira/browse/PDFBOX-3756 > Project: PDFBox > Issue Type: Bug > Components: Crypto >Affects Versions: 2.0.5 > Environment: java version "1.8.0_112" > Java(TM) SE Runtime Environment (build 1.8.0_112-b15) > Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode) >Reporter: Esteban Nicolas Ruiz > Labels: crypto > Attachments: pdfdebugger.png > > > I get the following stack trace when running: > java -jar pdfbox-app-2.0.5.jar PDFDebugger somefile.pdf > File is properly opened with other viewers, I cannot publish the pdf file due > to privacy restrictions. > java.io.IOException: javax.crypto.BadPaddingException: Given final block not > properly padded > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptDataAESother(SecurityHandler.java:296) > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:153) > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:454) > org.apache.pdfbox.pdfparser.COSParser.parseFileObject(COSParser.java:790) > > org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:747) > > org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:678) > org.apache.pdfbox.pdfparser.COSParser.parseDictObjects(COSParser.java:638) > org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:236) > org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:271) > org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:984) > org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:922) > > org.apache.pdfbox.debugger.PDFDebugger.parseDocument(PDFDebugger.java:1288) > org.apache.pdfbox.debugger.PDFDebugger.readPDFFile(PDFDebugger.java:1209) > org.apache.pdfbox.debugger.PDFDebugger.readPDFFile(PDFDebugger.java:1194) > org.apache.pdfbox.debugger.PDFDebugger.main(PDFDebugger.java:1185) > org.apache.pdfbox.tools.PDFBox.main(PDFBox.java:76) > Caused by: javax.crypto.BadPaddingException: Given final block not properly > padded > com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:989) > com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:845) > com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) > javax.crypto.Cipher.doFinal(Cipher.java:2048) > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptDataAESother(SecurityHandler.java:276) > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.encryptData(SecurityHandler.java:153) > > org.apache.pdfbox.pdmodel.encryption.SecurityHandler.decryptStream(SecurityHandler.java:454) > org.apache.pdfbox.pdfparser.COSParser.parseFileObject(COSParser.java:790) > > org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:747) > > org.apache.pdfbox.pdfparser.COSParser.parseObjectDynamically(COSParser.java:678) > org.apache.pdfbox.pdfparser.COSParser.parseDictObjects(COSParser.java:638) > org.apache.pdfbox.pdfparser.PDFParser.initialParse(PDFParser.java:236) > org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:271) > org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:984) > org.apache.pdfbox.pdmodel.PDDocument.load(PDDocument.java:922) > > org.apache.pdfbox.debugger.PDFDebugger.parseDocument(PDFDebugger.java:1288) > org.apache.pdfbox.debugger.PDFDebugger.readPDFFile(PDFDebugger.java:1209) > org.apache.pdfbox.debugger.PDFDebugger.readPDFFile(PDFDebugger.java:1194) > org.apache.pdfbox.debugger.PDFDebugger.main(PDFDebugger.java:1185) > org.apache.pdfbox.tools.PDFBox.main(PDFBox.java:76) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3732) IllegalArgumentException when refreshing an appearance and no font resources are defined
[
https://issues.apache.org/jira/browse/PDFBOX-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998762#comment-15998762
]
Maruan Sahyoun commented on PDFBOX-3732:
In addition to above comment there is also a {{/DA}} entry at the AcroForm
level generated by Adobe Reader {{/Helv 0 Tf 0 g }}
> IllegalArgumentException when refreshing an appearance and no font resources
> are defined
>
>
> Key: PDFBOX-3732
> URL: https://issues.apache.org/jira/browse/PDFBOX-3732
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: simon steiner
> Fix For: 2.0.6, 3.0.0
>
> Attachments: out.pdf, out-reader.pdf, PDFBOX3732-minimal.pdf,
> PDFBOX3732-minimal-reader.pdf, refreshAppearances.patch
>
>
> PDDocument doc = PDDocument.load(new File("out.pdf"));
> doc.getDocumentCatalog().getAcroForm().setNeedAppearances(false);
> doc.getDocumentCatalog().getAcroForm().refreshAppearances();
> doc.save("pdfbox.pdf");
> doc.close();
> Exception in thread "main" java.lang.IllegalArgumentException: /DR is a
> required entry
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.(PDDefaultAppearanceString.java:82)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-3732) IllegalArgumentException when refreshing an appearance and no font resources are defined
[
https://issues.apache.org/jira/browse/PDFBOX-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998734#comment-15998734
]
Maruan Sahyoun edited comment on PDFBOX-3732 at 5/5/17 6:32 PM:
For the sample form created by the above code from [~tilman] Adobe Reader will
add {{/Helv}} and {{/ZaDb}} resource entries to the PDF see
[^PDFBOX3732-minimal-reader.pdf].
For the file [^out.pdf] again {{/Helv}} and {{/ZaDb}} are added. In addition
the {{/F1}} entry from the appearance stream resources is taken and added to
the AcroForm {{/DR}} entry.
So I suggest to not implement the patch as is but replicate Adobe Acrobats
behavior.
was (Author: msahyoun):
For the sample form created by the above code from [~tilman] Adobe Reader will
add {{/Helv}} and {{ZaDb}} resource entries to the PDF see
[^PDFBOX3732-minimal-reader.pdf]].
For the file [^out.pdf] again {{/Helv}} and {{ZaDb}} are added. In addition the
{{/F1}} entry from the appearance stream resources is taken and added to the
AcroForm {{/DR}} entry.
So I suggest to not implement the patch as is but replicate Adobe Acrobats
behavior.
> IllegalArgumentException when refreshing an appearance and no font resources
> are defined
>
>
> Key: PDFBOX-3732
> URL: https://issues.apache.org/jira/browse/PDFBOX-3732
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: simon steiner
> Fix For: 2.0.6, 3.0.0
>
> Attachments: out.pdf, out-reader.pdf, PDFBOX3732-minimal.pdf,
> PDFBOX3732-minimal-reader.pdf, refreshAppearances.patch
>
>
> PDDocument doc = PDDocument.load(new File("out.pdf"));
> doc.getDocumentCatalog().getAcroForm().setNeedAppearances(false);
> doc.getDocumentCatalog().getAcroForm().refreshAppearances();
> doc.save("pdfbox.pdf");
> doc.close();
> Exception in thread "main" java.lang.IllegalArgumentException: /DR is a
> required entry
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.(PDDefaultAppearanceString.java:82)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3732) IllegalArgumentException when refreshing an appearance and no font resources are defined
[
https://issues.apache.org/jira/browse/PDFBOX-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998734#comment-15998734
]
Maruan Sahyoun commented on PDFBOX-3732:
For the sample form created by the above code from [~tilman] Adobe Reader will
add {{/Helv}} and {{ZaDb}} resource entries to the PDF see
[^PDFBOX3732-minimal-reader.pdf]].
For the file [^out.pdf] again {{/Helv}} and {{ZaDb}} are added. In addition the
{{/F1}} entry from the appearance stream resources is taken and added to the
AcroForm {{/DR}} entry.
So I suggest to not implement the patch as is but replicate Adobe Acrobats
behavior.
> IllegalArgumentException when refreshing an appearance and no font resources
> are defined
>
>
> Key: PDFBOX-3732
> URL: https://issues.apache.org/jira/browse/PDFBOX-3732
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: simon steiner
> Fix For: 2.0.6, 3.0.0
>
> Attachments: out.pdf, out-reader.pdf, PDFBOX3732-minimal.pdf,
> PDFBOX3732-minimal-reader.pdf, refreshAppearances.patch
>
>
> PDDocument doc = PDDocument.load(new File("out.pdf"));
> doc.getDocumentCatalog().getAcroForm().setNeedAppearances(false);
> doc.getDocumentCatalog().getAcroForm().refreshAppearances();
> doc.save("pdfbox.pdf");
> doc.close();
> Exception in thread "main" java.lang.IllegalArgumentException: /DR is a
> required entry
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.(PDDefaultAppearanceString.java:82)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3732) IllegalArgumentException when refreshing an appearance and no font resources are defined
[
https://issues.apache.org/jira/browse/PDFBOX-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun updated PDFBOX-3732:
---
Attachment: PDFBOX3732-minimal.pdf
PDFBOX3732-minimal-reader.pdf
[^PDFBOX3732-minimal.pdf] example form generated by [~tilman] code
[^PDFBOX3732-minimal-reader.pdf] opened and save with Adobe Reader
> IllegalArgumentException when refreshing an appearance and no font resources
> are defined
>
>
> Key: PDFBOX-3732
> URL: https://issues.apache.org/jira/browse/PDFBOX-3732
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: simon steiner
> Fix For: 2.0.6, 3.0.0
>
> Attachments: out.pdf, PDFBOX3732-minimal.pdf,
> PDFBOX3732-minimal-reader.pdf, refreshAppearances.patch
>
>
> PDDocument doc = PDDocument.load(new File("out.pdf"));
> doc.getDocumentCatalog().getAcroForm().setNeedAppearances(false);
> doc.getDocumentCatalog().getAcroForm().refreshAppearances();
> doc.save("pdfbox.pdf");
> doc.close();
> Exception in thread "main" java.lang.IllegalArgumentException: /DR is a
> required entry
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDDefaultAppearanceString.(PDDefaultAppearanceString.java:82)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[ https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998705#comment-15998705 ] ASF subversion and git services commented on PDFBOX-3545: - Commit 1794091 from [~lehmi] in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1794091 ] PDFBOX-3545: added null check > COSParser.parseXref failing if startXrefOffset over pdf size > > > Key: PDFBOX-3545 > URL: https://issues.apache.org/jira/browse/PDFBOX-3545 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Matus Zamborsky >Assignee: Andreas Lehmkühler > Fix For: 2.0.6, 3.0.0 > > Attachments: 000369.pdf > > > Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8 > thanks to self healing mechanism. > In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek > to the startxref position. > If the position is wrong, but within the file size, the PDF is parsed with > warning. > But when the startxref is over the file size, the parsing ended with > exception. > We could either test if startxref is not over source.length(), or catch the > exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[ https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998704#comment-15998704 ] ASF subversion and git services commented on PDFBOX-3545: - Commit 1794090 from [~lehmi] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1794090 ] PDFBOX-3545: added null check > COSParser.parseXref failing if startXrefOffset over pdf size > > > Key: PDFBOX-3545 > URL: https://issues.apache.org/jira/browse/PDFBOX-3545 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Matus Zamborsky >Assignee: Andreas Lehmkühler > Fix For: 2.0.6, 3.0.0 > > Attachments: 000369.pdf > > > Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8 > thanks to self healing mechanism. > In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek > to the startxref position. > If the position is wrong, but within the file size, the PDF is parsed with > warning. > But when the startxref is over the file size, the parsing ended with > exception. > We could either test if startxref is not over source.length(), or catch the > exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Reopened] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[
https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr reopened PDFBOX-3545:
-
I get an NPE with some files, e.g. PDFBOX-3318 here:
{code}
if (isLenient() && trailer.getItem(COSName.ROOT) == null)
{code}
Maybe add a null check for trailer?
Btw the file in that issue worked before the change.
> COSParser.parseXref failing if startXrefOffset over pdf size
>
>
> Key: PDFBOX-3545
> URL: https://issues.apache.org/jira/browse/PDFBOX-3545
> Project: PDFBox
> Issue Type: Bug
>Affects Versions: 2.0.3
>Reporter: Matus Zamborsky
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.6, 3.0.0
>
> Attachments: 000369.pdf
>
>
> Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8
> thanks to self healing mechanism.
> In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek
> to the startxref position.
> If the position is wrong, but within the file size, the PDF is parsed with
> warning.
> But when the startxref is over the file size, the parsing ended with
> exception.
> We could either test if startxref is not over source.length(), or catch the
> exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2852) Improve code quality (2)
[ https://issues.apache.org/jira/browse/PDFBOX-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998631#comment-15998631 ] Tilman Hausherr commented on PDFBOX-2852: - Commit 1794080 from Tilman Hausherr in branch 'pdfbox/trunk' [ https://svn.apache.org/r1794080 ] PDFBOX-2852: remove tabs Commit 1794081 from Tilman Hausherr in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1794081 ] PDFBOX-2852: remove tabs > Improve code quality (2) > > > Key: PDFBOX-2852 > URL: https://issues.apache.org/jira/browse/PDFBOX-2852 > Project: PDFBox > Issue Type: Task >Affects Versions: 2.0.0 >Reporter: Tilman Hausherr > Attachments: explicit_array_creation.patch, fix_javadoc.patch, > foreach2.patch, foreach.patch, generic_type_arguments.patch, noarray.patch, > PDNameTreeNode.java.patch, semicolon.patch, StringBuffer.patch, > stringbuilder.patch, unnecessary_type_casting.patch, unused_imports.patch, > usestatic.patch, winansiencoding2.patch, winansiencoding.patch, > XMPSchema.java.patch > > > This is a longterm issue for the task to improve code quality, by using the > [SonarQube > report|https://analysis.apache.org/dashboard/index/org.apache.pdfbox:pdfbox-reactor], > hints in different IDEs, the FindBugs tool and other code quality tools. > This is a follow-up of PDFBOX-2576, which was getting too long. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3778) Create sample code for creating a PDF with type 4 shading
[ https://issues.apache.org/jira/browse/PDFBOX-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998624#comment-15998624 ] Tilman Hausherr commented on PDFBOX-3778: - ignore the last two commits, these belong to PDFBOX-2852. > Create sample code for creating a PDF with type 4 shading > - > > Key: PDFBOX-3778 > URL: https://issues.apache.org/jira/browse/PDFBOX-3778 > Project: PDFBox > Issue Type: Task > Components: PDModel >Affects Versions: 2.0.5 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr > Labels: shading, shadingpattern > Fix For: 2.0.6, 3.0.0 > > > Add sample code to existing example CreateGradientShadingPDF.java . -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3778) Create sample code for creating a PDF with type 4 shading
[ https://issues.apache.org/jira/browse/PDFBOX-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998622#comment-15998622 ] ASF subversion and git services commented on PDFBOX-3778: - Commit 1794080 from [~tilman] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1794080 ] PDFBOX-3778: remove tabs > Create sample code for creating a PDF with type 4 shading > - > > Key: PDFBOX-3778 > URL: https://issues.apache.org/jira/browse/PDFBOX-3778 > Project: PDFBox > Issue Type: Task > Components: PDModel >Affects Versions: 2.0.5 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr > Labels: shading, shadingpattern > Fix For: 2.0.6, 3.0.0 > > > Add sample code to existing example CreateGradientShadingPDF.java . -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3778) Create sample code for creating a PDF with type 4 shading
[ https://issues.apache.org/jira/browse/PDFBOX-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998623#comment-15998623 ] ASF subversion and git services commented on PDFBOX-3778: - Commit 1794081 from [~tilman] in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1794081 ] PDFBOX-3778: remove tabs > Create sample code for creating a PDF with type 4 shading > - > > Key: PDFBOX-3778 > URL: https://issues.apache.org/jira/browse/PDFBOX-3778 > Project: PDFBox > Issue Type: Task > Components: PDModel >Affects Versions: 2.0.5 >Reporter: Tilman Hausherr >Assignee: Tilman Hausherr > Labels: shading, shadingpattern > Fix For: 2.0.6, 3.0.0 > > > Add sample code to existing example CreateGradientShadingPDF.java . -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[ https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-3545. Resolution: Fixed Fix Version/s: 3.0.0 2.0.6 > COSParser.parseXref failing if startXrefOffset over pdf size > > > Key: PDFBOX-3545 > URL: https://issues.apache.org/jira/browse/PDFBOX-3545 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Matus Zamborsky >Assignee: Andreas Lehmkühler > Fix For: 2.0.6, 3.0.0 > > Attachments: 000369.pdf > > > Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8 > thanks to self healing mechanism. > In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek > to the startxref position. > If the position is wrong, but within the file size, the PDF is parsed with > warning. > But when the startxref is over the file size, the parsing ended with > exception. > We could either test if startxref is not over source.length(), or catch the > exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[ https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998545#comment-15998545 ] ASF subversion and git services commented on PDFBOX-3545: - Commit 1794073 from [~lehmi] in branch 'pdfbox/trunk' [ https://svn.apache.org/r1794073 ] PDFBOX-3545: rebuild trailer if Root object is missing > COSParser.parseXref failing if startXrefOffset over pdf size > > > Key: PDFBOX-3545 > URL: https://issues.apache.org/jira/browse/PDFBOX-3545 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Matus Zamborsky >Assignee: Andreas Lehmkühler > Attachments: 000369.pdf > > > Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8 > thanks to self healing mechanism. > In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek > to the startxref position. > If the position is wrong, but within the file size, the PDF is parsed with > warning. > But when the startxref is over the file size, the parsing ended with > exception. > We could either test if startxref is not over source.length(), or catch the > exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Assigned] (PDFBOX-3545) COSParser.parseXref failing if startXrefOffset over pdf size
[ https://issues.apache.org/jira/browse/PDFBOX-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler reassigned PDFBOX-3545: -- Assignee: Andreas Lehmkühler > COSParser.parseXref failing if startXrefOffset over pdf size > > > Key: PDFBOX-3545 > URL: https://issues.apache.org/jira/browse/PDFBOX-3545 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Matus Zamborsky >Assignee: Andreas Lehmkühler > Attachments: 000369.pdf > > > Any PDF which had wrong startxref was parsed with warning in PdfBox 1.8 > thanks to self healing mechanism. > In version 2.0 the COSParser.parseXref (called from PDFParser) tries to seek > to the startxref position. > If the position is wrong, but within the file size, the PDF is parsed with > warning. > But when the startxref is over the file size, the parsing ended with > exception. > We could either test if startxref is not over source.length(), or catch the > exception. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-3519.
Resolution: Fixed
I've merged Maruans changes to the 2.0 branch as well. Set to resolved
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Assignee: Andreas Lehmkühler
>Priority: Minor
> Fix For: 2.0.6, 3.0.0
>
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3347) COSName parsing doesn't handle ISO-8859-1 encoded bytes
[ https://issues.apache.org/jira/browse/PDFBOX-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-3347. Resolution: Fixed Fix Version/s: (was: 2.0.2) 3.0.0 2.0.6 I've committed the changes to the 2.0 branch [~jahewson] There isn't any magic which merges changes from the trunk to any of the branches > COSName parsing doesn't handle ISO-8859-1 encoded bytes > --- > > Key: PDFBOX-3347 > URL: https://issues.apache.org/jira/browse/PDFBOX-3347 > Project: PDFBox > Issue Type: Bug > Components: Parsing, Writing >Affects Versions: 1.8.12, 2.0.1, 2.0.2 >Reporter: Maruan Sahyoun >Assignee: John Hewson >Priority: Minor > Fix For: 2.0.6, 3.0.0 > > > As discussed here > http://stackoverflow.com/questions/36964496/pdfbox-2-0-overcoming-dictionary-key-encoding/ > a byte sequence making up a COSName is interpreted during parsing and > writing where it shouldn't. Details are given my mkl's excellent analysis. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3347) COSName parsing doesn't handle ISO-8859-1 encoded bytes
[ https://issues.apache.org/jira/browse/PDFBOX-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998501#comment-15998501 ] ASF subversion and git services commented on PDFBOX-3347: - Commit 1794069 from [~lehmi] in branch 'pdfbox/branches/2.0' [ https://svn.apache.org/r1794069 ] PDFBOX-3347: fallback to ISO-8859-1 for names with invalid UTF-8 > COSName parsing doesn't handle ISO-8859-1 encoded bytes > --- > > Key: PDFBOX-3347 > URL: https://issues.apache.org/jira/browse/PDFBOX-3347 > Project: PDFBox > Issue Type: Bug > Components: Parsing, Writing >Affects Versions: 1.8.12, 2.0.1, 2.0.2 >Reporter: Maruan Sahyoun >Assignee: John Hewson >Priority: Minor > Fix For: 2.0.2 > > > As discussed here > http://stackoverflow.com/questions/36964496/pdfbox-2-0-overcoming-dictionary-key-encoding/ > a byte sequence making up a COSName is interpreted during parsing and > writing where it shouldn't. Details are given my mkl's excellent analysis. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Reopened] (PDFBOX-3347) COSName parsing doesn't handle ISO-8859-1 encoded bytes
[ https://issues.apache.org/jira/browse/PDFBOX-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler reopened PDFBOX-3347: THe fix version is wrong as the changes weren't committed to the 2.0 branch > COSName parsing doesn't handle ISO-8859-1 encoded bytes > --- > > Key: PDFBOX-3347 > URL: https://issues.apache.org/jira/browse/PDFBOX-3347 > Project: PDFBox > Issue Type: Bug > Components: Parsing, Writing >Affects Versions: 1.8.12, 2.0.1, 2.0.2 >Reporter: Maruan Sahyoun >Assignee: John Hewson >Priority: Minor > Fix For: 2.0.2 > > > As discussed here > http://stackoverflow.com/questions/36964496/pdfbox-2-0-overcoming-dictionary-key-encoding/ > a byte sequence making up a COSName is interpreted during parsing and > writing where it shouldn't. Details are given my mkl's excellent analysis. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3753) setting a RadioButton with export values does not update the appearance
[
https://issues.apache.org/jira/browse/PDFBOX-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998410#comment-15998410
]
ASF subversion and git services commented on PDFBOX-3753:
-
Commit 1794061 from [~msahyoun] in branch 'pdfbox/branches/2.0'
[ https://svn.apache.org/r1794061 ]
PDFBOX-3753: set the radio button value by the index of the widget the /Opts
entry refers to.
> setting a RadioButton with export values does not update the appearance
> ---
>
> Key: PDFBOX-3753
> URL: https://issues.apache.org/jira/browse/PDFBOX-3753
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: Travis Schneeberger
>Assignee: Maruan Sahyoun
> Fix For: 2.0.6, 3.0.0
>
> Attachments: fdpAttachment2.pdf, fdpAttachment2-radio-buttons.pdf,
> fdpAttachment2-radio-buttons-workaround.pdf
>
>
> Setting a RadioButton with export values does not update the appearance. The
> attached form has two sets of RadioButtons. One called "Group1" and one
> called "\_6_ Treatment of Program Inco_nwAbuWIn0JWsW9e68RWN8A". "Group1" is
> easy to set or unset. I noticed during debugging doesn't have any
> "ExportValues" and so the value is set in a different way than the other set
> of RadioButtons. "\_6_ Treatment of Program Inco_nwAbuWIn0JWsW9e68RWN8A"
> does have ExportValues and this appears to be related to the problems with
> setting the value.
> For example:
> {code}
> try(PDDocument pdfDocument = PDDocument.load(new
> File("/Users/travis/Desktop/fdpAttachment2.pdf"))) {
> final PDDocumentCatalog docCatalog =
> pdfDocument.getDocumentCatalog();
> final PDAcroForm acroForm = docCatalog.getAcroForm();
> final PDRadioButton group1Field = (PDRadioButton)
> acroForm.getField("Group1");
> group1Field.setValue("NIH");
> final PDRadioButton topiField = (PDRadioButton)
> acroForm.getField("_6_ Treatment of Program Inco_nwAbuWIn0JWsW9e68RWN8A");
> topiField.setValue("Additive");
>
> pdfDocument.save("/Users/travis/Desktop/fdpAttachment2-radio-buttons.pdf");
> }
> {code}
> Notice in "fdpAttachment2-radio-buttons.pdf" that "Group1" RadioButton has
> NIH toggled while "\_6_ Treatment of Program Inco_nwAbuWIn0JWsW9e68RWN8A" is
> not toggled even though "Additive" is a valid value.
> The workaround for this is to set the appearance state (AS). I'm still
> learning the pdfbox api so I apologize if my workaround is a little strange.
> {code}
> try(PDDocument pdfDocument = PDDocument.load(new
> File("/Users/travis/Desktop/fdpAttachment2.pdf"))) {
> final PDDocumentCatalog docCatalog =
> pdfDocument.getDocumentCatalog();
> final PDAcroForm acroForm = docCatalog.getAcroForm();
> final PDRadioButton group1Field = (PDRadioButton)
> acroForm.getField("Group1");
> group1Field.setValue("NIH");
> final PDRadioButton topiField = (PDRadioButton)
> acroForm.getField("_6_ Treatment of Program Inco_nwAbuWIn0JWsW9e68RWN8A");
> topiField.setValue("Additive");
> //Additive ends up being index 0. If I add an AS with "0" it
> toggle the Additive radio button
> final int idx =
> topiField.getExportValues().indexOf((topiField).getValue());
> topiField.getWidgets().forEach(w -> {
> PDAppearanceEntry appearanceEntry =
> w.getAppearance().getNormalAppearance();
> if (((COSDictionary)
> appearanceEntry.getCOSObject()).containsKey(String.valueOf(idx))) {
> w.getCOSObject().setName(COSName.AS, String.valueOf(idx));
> }
> });
>
> pdfDocument.save("/Users/travis/Desktop/fdpAttachment2-radio-buttons-workaround.pdf");
> }
> {code}
> Notice in "fdpAttachment2-radio-buttons-workaround.pdf" both sets of
> RadioButtons are toggled which is the desired behavior
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3752) PDVariableText text color changes to be the same as the background color after flattening
[
https://issues.apache.org/jira/browse/PDFBOX-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maruan Sahyoun resolved PDFBOX-3752.
Resolution: Fixed
setting to resolved [~leo.herbie] if there are still issues please reopen
> PDVariableText text color changes to be the same as the background color
> after flattening
> -
>
> Key: PDFBOX-3752
> URL: https://issues.apache.org/jira/browse/PDFBOX-3752
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.5
>Reporter: Travis Schneeberger
>Assignee: Maruan Sahyoun
> Fix For: 2.0.6, 3.0.0
>
> Attachments: fdpAttachment2-example-flattened.pdf,
> fdpAttachment2-example-not-flattened.pdf, fdpAttachment2.pdf
>
>
> PDVariableText text color changes to be the same as the background color
> after flattening. This effectively makes the text hidden and appear to be
> lost.
> This includes field types such as ListBox and TextField. I don't believe I
> have tested a combo box.
> For example:
> {code}
> try(PDDocument pdfDocument = PDDocument.load(new
> File("/Users/travis/Desktop/fdpAttachment2.pdf"))) {
> final PDDocumentCatalog docCatalog =
> pdfDocument.getDocumentCatalog();
> final PDAcroForm acroForm = docCatalog.getAcroForm();
> final PDField textField = acroForm.getField("Subaward Number");
> textField.setValue("12345");
> final PDField listBoxField = acroForm.getField("Contact for
> carryforward");
> listBoxField.setValue("Administrative Contact");
> //when flattening with refreshAppearances, a NPE will occur if
> each widget doesn't have a
> //PDAppearanceDictionary instance with a normal PDAppearanceEntry
> instance set PDFBOX-3751
> pdfDocument.getDocumentCatalog().getAcroForm().getFields()
> .stream()
> .flatMap(f -> f.getWidgets().stream())
> .filter(w -> w.getAppearance() == null)
> .forEach(w -> {
> final PDAppearanceDictionary appearance = new
> PDAppearanceDictionary(new COSDictionary());
> appearance.setNormalAppearance(new
> PDAppearanceEntry(new COSDictionary()));
> w.setAppearance(appearance);
> });
> pdfDocument.getDocumentCatalog().getAcroForm().flatten(pdfDocument.getDocumentCatalog().getAcroForm().getFields(),
> true);
>
> pdfDocument.save("/Users/travis/Desktop/fdpAttachment2-example-flattened.pdf");
> }
> {code}
> Notice in the attached fdpAttachment2-example-flattened.pdf, the fields are
> correctly set but the text is not visible.
> If I execute the same code but do not flatten, the text is visible for
> certain field types in certain pdf viewers. See attached
> fdpAttachment2-example-not-flattened.pdf
> In Adobe Acrobat Reader DC build 15.23.20056.213124 the "Subaward Number"
> field shows up but only when clicking on the field. When using the Preview
> app in MacOS Sierra, it is visible. In both apps the "Contact for
> carryforward" list box shows the text "Administrative Contact"
> As a side note I wonder if the behavior of the "Subaward Number" in relation
> to different pdf views may be related to a difference problem. I think the
> real issue here is the text color.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3780) Heights of Characters
Uwe Möser created PDFBOX-3780: - Summary: Heights of Characters Key: PDFBOX-3780 URL: https://issues.apache.org/jira/browse/PDFBOX-3780 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 2.0.5 Reporter: Uwe Möser Priority: Critical Attachments: DejaVuSansCondensed-Bold.ttf, DejaVuSansCondensed.ttf, PDFBoxHeightTest.java, PDFBoxHeightTest.pdf the functions .getFontDescriptor().getCapHeight() .getFontDescriptor().getXHeight() .getFontDescriptor().getAscent() .getFontDescriptor().getDescent() getHeight(int code) do not work proper especially for embedded fonts, PDType0Font . Please see the attached file PDFBoxHeightTest.pdf where the line is and should be. The fonts were downloaded from http://www.schriftarten-fonts.de/fonts/11283/dejavu_sans_condensed.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler updated PDFBOX-3519:
---
Fix Version/s: 2.0.6
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Assignee: Andreas Lehmkühler
>Priority: Minor
> Fix For: 2.0.6, 3.0.0
>
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Assigned] (PDFBOX-3519) COSName is not ascii
[
https://issues.apache.org/jira/browse/PDFBOX-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler reassigned PDFBOX-3519:
--
Assignee: Andreas Lehmkühler
> COSName is not ascii
>
>
> Key: PDFBOX-3519
> URL: https://issues.apache.org/jira/browse/PDFBOX-3519
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
>Affects Versions: 2.0.3
>Reporter: simon steiner
>Assignee: Andreas Lehmkühler
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: COSNameAcrobat.png
>
>
> Trunk seems ok
> PDF is from PDFBOX-783
> {code}
> public static void main( String[] args ) throws IOException {
> PDDocument doc = PDDocument.load(new File("A02Gj780LZ.pdf"));
> COSDictionary x = doc.getPage(0).getResources().getCOSObject();
> read(x);
> doc.close();
> }
> private static void read(COSBase b) {
> if (b instanceof COSObject) {
> read(((COSObject) b).getObject());
> } else if (b instanceof COSDictionary) {
> for (COSBase x : ((COSDictionary) b).getValues()) {
> read(x);
> }
> } else if (b instanceof COSName) {
> if(((COSName) b).getName().charAt(0) > 256)
> throw new RuntimeException(((COSName) b).getName());
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-3614) Directly use the BouncyCastleProvider rather than installing it
[
https://issues.apache.org/jira/browse/PDFBOX-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-3614.
Resolution: Fixed
Assignee: Andreas Lehmkühler
The solution provided by PDFBOX-2963 should solve this issue as well as PDFBox
doesn't use insertProvider anymore.
> Directly use the BouncyCastleProvider rather than installing it
> ---
>
> Key: PDFBOX-3614
> URL: https://issues.apache.org/jira/browse/PDFBOX-3614
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Jay Modi
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.6, 3.0.0
>
> Attachments: bcprov.patch
>
>
> The BouncyCastleProvider is in installed in a static block and this makes it
> available to other code, when the usage can be contained to a single class
> inside of PDFBox by using the provider directly.
> Doing this also has the added advantage of not requiring additional security
> permissions when running code that is protected by a SecurityManager.
> Currently one needs to grant {code}permission
> java.security.SecurityPermission "insertProvider"{code} since the provider is
> being installed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-3614) Directly use the BouncyCastleProvider rather than installing it
[
https://issues.apache.org/jira/browse/PDFBOX-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler updated PDFBOX-3614:
---
Fix Version/s: 3.0.0
2.0.6
> Directly use the BouncyCastleProvider rather than installing it
> ---
>
> Key: PDFBOX-3614
> URL: https://issues.apache.org/jira/browse/PDFBOX-3614
> Project: PDFBox
> Issue Type: Improvement
>Affects Versions: 2.0.3
>Reporter: Jay Modi
> Fix For: 2.0.6, 3.0.0
>
> Attachments: bcprov.patch
>
>
> The BouncyCastleProvider is in installed in a static block and this makes it
> available to other code, when the usage can be contained to a single class
> inside of PDFBox by using the provider directly.
> Doing this also has the added advantage of not requiring additional security
> permissions when running code that is protected by a SecurityManager.
> Currently one needs to grant {code}permission
> java.security.SecurityPermission "insertProvider"{code} since the provider is
> being installed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Resolved] (PDFBOX-2963) Remove Bouncy Castle Provider Reference
[
https://issues.apache.org/jira/browse/PDFBOX-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-2963.
Resolution: Fixed
Set to resolved as the hardcoded reference to the bouncy castle provider was
removed.
Regarding the remaining dependency in
{{org.apache.pdfbox.pdmodel.encryption.PublicKeySecurityHandler}}:
We would need to replace the ASN parser and AFAIU JCE doesn't provide one.
Maybe the Apache Harmony ASN parser could be used, but that's a different
story. However, we should create another JIRA ticket if we decide to replace
the parser.
> Remove Bouncy Castle Provider Reference
> ---
>
> Key: PDFBOX-2963
> URL: https://issues.apache.org/jira/browse/PDFBOX-2963
> Project: PDFBox
> Issue Type: Improvement
> Components: Crypto, PDModel
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Johnny Minty
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.6, 3.0.0
>
>
> PDFBox Versions 1.8.X and 2.0.X add Bouncy Castle as a security provider
> explicitly (Hard coded)
> Referencing bouncy castle explicitly ties PDF box to a specific provider
> implementation.
> Instead of referencing BouncyCastleProvider explicitly provide an option to
> select another provider or alternatively allow a way to override the default.
> Version 1.8.X:
> https://github.com/apache/pdfbox/blob/1.8.10/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandlersManager.java
> {code}
> public static SecurityHandlersManager getInstance()
> {
> if(instance == null)
> {
> instance = new SecurityHandlersManager();
> Security.addProvider(new BouncyCastleProvider());
> }
> return instance;
> }
> {code}
> Version 2.0.0:
> https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandlerFactory.java
> {code}
>static
> {
> Security.addProvider(new BouncyCastleProvider());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-2963) Remove Bouncy Castle Provider Reference
[
https://issues.apache.org/jira/browse/PDFBOX-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler updated PDFBOX-2963:
---
Summary: Remove Bouncy Castle Provider Reference (was: Remove Bouncy
Castle Reference)
> Remove Bouncy Castle Provider Reference
> ---
>
> Key: PDFBOX-2963
> URL: https://issues.apache.org/jira/browse/PDFBOX-2963
> Project: PDFBox
> Issue Type: Improvement
> Components: Crypto, PDModel
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Johnny Minty
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.6, 3.0.0
>
>
> PDFBox Versions 1.8.X and 2.0.X add Bouncy Castle as a security provider
> explicitly (Hard coded)
> Referencing bouncy castle explicitly ties PDF box to a specific provider
> implementation.
> Instead of referencing BouncyCastleProvider explicitly provide an option to
> select another provider or alternatively allow a way to override the default.
> Version 1.8.X:
> https://github.com/apache/pdfbox/blob/1.8.10/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandlersManager.java
> {code}
> public static SecurityHandlersManager getInstance()
> {
> if(instance == null)
> {
> instance = new SecurityHandlersManager();
> Security.addProvider(new BouncyCastleProvider());
> }
> return instance;
> }
> {code}
> Version 2.0.0:
> https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandlerFactory.java
> {code}
>static
> {
> Security.addProvider(new BouncyCastleProvider());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
