[jira] Created: (PDFBOX-837) Wrong RevisionNumber when disabling all permissions and using 128bit encryption
Wrong RevisionNumber when disabling all permissions and using 128bit encryption
---
Key: PDFBOX-837
URL: https://issues.apache.org/jira/browse/PDFBOX-837
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.2.1
Reporter: Bernd Engelhardt
When disabling all permissions and using a 128bit encryption the following
exception is thrown when saving the PDF document:
org.apache.pdfbox.exceptions.COSVisitorException: Error: Expected length=5
actual=16
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1022)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:911)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:892)
at pdfbox.Main.main(Main.java:53)
This is reproducable with the following code:
public class Main {
public static void main(String[] args) {
try {
AccessPermission ap = new AccessPermission();
StandardProtectionPolicy spp = null;
ap.setCanAssembleDocument(false);
ap.setCanExtractContent(false);
ap.setCanExtractForAccessibility(false);
ap.setCanFillInForm(false);
ap.setCanModify(false);
ap.setCanModifyAnnotations(false);
ap.setCanPrint(false);
ap.setCanPrintDegraded(false);
spp = new StandardProtectionPolicy(null, null, ap);
spp.setEncryptionKeyLength(128);
PDDocument document = null;
FileInputStream sourceFile = new FileInputStream(new
File(C:\\Web\\NetBeansProjects\\pdfBox\\test.pdf));
document = PDDocument.load(sourceFile);
document.protect(spp);
document.save(C:\\Web\\NetBeansProjects\\pdfBox\\test_encrypted.pdf);
document.close();
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
The problem is based on computeRevisionNumber in
StandardSecurityHandler.java. If all flags are disabled, the routine returns
a value of 2. But if the 128bit encryption is enabled, the revision should be
3. If not, the method computeUserPassword will fail.
A solution would be to check the key length in computeRevisionNumber.
private int computeRevisionNumber()
{
if(version == 2
!policy.getPermissions().canFillInForm()
!policy.getPermissions().canExtractForAccessibility()
!policy.getPermissions().canPrintDegraded()
keyLength == 40 )
{
return 2;
}
return 3;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PDFBOX-837) Wrong RevisionNumber when disabling all permissions and using 128bit encryption
[
https://issues.apache.org/jira/browse/PDFBOX-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Engelhardt updated PDFBOX-837:
Attachment: StandardSecurityHandler_patch.patch
Patch for StandardSecurityHandler (Trunk, Rev 999590)
Wrong RevisionNumber when disabling all permissions and using 128bit
encryption
---
Key: PDFBOX-837
URL: https://issues.apache.org/jira/browse/PDFBOX-837
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.2.1
Reporter: Bernd Engelhardt
Attachments: StandardSecurityHandler_patch.patch
When disabling all permissions and using a 128bit encryption the following
exception is thrown when saving the PDF document:
org.apache.pdfbox.exceptions.COSVisitorException: Error: Expected length=5
actual=16
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1022)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:911)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:892)
at pdfbox.Main.main(Main.java:53)
This is reproducable with the following code:
public class Main {
public static void main(String[] args) {
try {
AccessPermission ap = new AccessPermission();
StandardProtectionPolicy spp = null;
ap.setCanAssembleDocument(false);
ap.setCanExtractContent(false);
ap.setCanExtractForAccessibility(false);
ap.setCanFillInForm(false);
ap.setCanModify(false);
ap.setCanModifyAnnotations(false);
ap.setCanPrint(false);
ap.setCanPrintDegraded(false);
spp = new StandardProtectionPolicy(null, null, ap);
spp.setEncryptionKeyLength(128);
PDDocument document = null;
FileInputStream sourceFile = new FileInputStream(new
File(C:\\Web\\NetBeansProjects\\pdfBox\\test.pdf));
document = PDDocument.load(sourceFile);
document.protect(spp);
document.save(C:\\Web\\NetBeansProjects\\pdfBox\\test_encrypted.pdf);
document.close();
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
The problem is based on computeRevisionNumber in
StandardSecurityHandler.java. If all flags are disabled, the routine
returns a value of 2. But if the 128bit encryption is enabled, the revision
should be 3. If not, the method computeUserPassword will fail.
A solution would be to check the key length in computeRevisionNumber.
private int computeRevisionNumber()
{
if(version == 2
!policy.getPermissions().canFillInForm()
!policy.getPermissions().canExtractForAccessibility()
!policy.getPermissions().canPrintDegraded()
keyLength == 40 )
{
return 2;
}
return 3;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PDFBOX-837) Wrong RevisionNumber when disabling all permissions and using 128bit encryption
[
https://issues.apache.org/jira/browse/PDFBOX-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Engelhardt updated PDFBOX-837:
Fix Version/s: 1.2.1
Wrong RevisionNumber when disabling all permissions and using 128bit
encryption
---
Key: PDFBOX-837
URL: https://issues.apache.org/jira/browse/PDFBOX-837
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.2.1
Reporter: Bernd Engelhardt
Fix For: 1.2.1
Attachments: StandardSecurityHandler_patch.patch
When disabling all permissions and using a 128bit encryption the following
exception is thrown when saving the PDF document:
org.apache.pdfbox.exceptions.COSVisitorException: Error: Expected length=5
actual=16
at org.apache.pdfbox.pdfwriter.COSWriter.write(COSWriter.java:1022)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:911)
at org.apache.pdfbox.pdmodel.PDDocument.save(PDDocument.java:892)
at pdfbox.Main.main(Main.java:53)
This is reproducable with the following code:
public class Main {
public static void main(String[] args) {
try {
AccessPermission ap = new AccessPermission();
StandardProtectionPolicy spp = null;
ap.setCanAssembleDocument(false);
ap.setCanExtractContent(false);
ap.setCanExtractForAccessibility(false);
ap.setCanFillInForm(false);
ap.setCanModify(false);
ap.setCanModifyAnnotations(false);
ap.setCanPrint(false);
ap.setCanPrintDegraded(false);
spp = new StandardProtectionPolicy(null, null, ap);
spp.setEncryptionKeyLength(128);
PDDocument document = null;
FileInputStream sourceFile = new FileInputStream(new
File(C:\\Web\\NetBeansProjects\\pdfBox\\test.pdf));
document = PDDocument.load(sourceFile);
document.protect(spp);
document.save(C:\\Web\\NetBeansProjects\\pdfBox\\test_encrypted.pdf);
document.close();
} catch (Exception ex) {
Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
The problem is based on computeRevisionNumber in
StandardSecurityHandler.java. If all flags are disabled, the routine
returns a value of 2. But if the 128bit encryption is enabled, the revision
should be 3. If not, the method computeUserPassword will fail.
A solution would be to check the key length in computeRevisionNumber.
private int computeRevisionNumber()
{
if(version == 2
!policy.getPermissions().canFillInForm()
!policy.getPermissions().canExtractForAccessibility()
!policy.getPermissions().canPrintDegraded()
keyLength == 40 )
{
return 2;
}
return 3;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Updated] (PDFBOX-3613) FDFField creates wrong object type, when loaded from XML
[
https://issues.apache.org/jira/browse/PDFBOX-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Engelhardt updated PDFBOX-3613:
-
Attachment: FDF_Import.patch
> FDFField creates wrong object type, when loaded from XML
>
>
> Key: PDFBOX-3613
> URL: https://issues.apache.org/jira/browse/PDFBOX-3613
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.3
>Reporter: Bernd Engelhardt
> Fix For: 2.0.3
>
> Attachments: FDF_Import.patch
>
>
> When a FDFDocument is loaded from file with
> {code}
> FDFDocument fdfDocument = FDFDocument.loadXFDF(is)
> {code}
> and afterwards the same documet is saved via
> {code}
> fdfDocument.saveXFDF(...)
> {code}
> the output document contains only empty fields. The problem is that
> {code}
> FDFField(Element fieldXML)
> {code}
> creates with "setValue" not a "COSString", what is expected by "getValue",
> when saving the document.
> FDFField should use
> {code}
> setValue(new COSString(XMLUtil.getNodeValue(child)));
> {code}
> to create correct values for the XML nodes. Otherwise the import of FDF
> documents via e.g.
> {code}
> pdAcroForm.importFDF
> {code}
> does not work correct.
> Patch for 2.0.3 is attached.
--
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-3613) FDFField creates wrong object type, when loaded from XML
Bernd Engelhardt created PDFBOX-3613:
Summary: FDFField creates wrong object type, when loaded from XML
Key: PDFBOX-3613
URL: https://issues.apache.org/jira/browse/PDFBOX-3613
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 2.0.3
Reporter: Bernd Engelhardt
Fix For: 2.0.3
When a FDFDocument is loaded from file with
{code}
FDFDocument fdfDocument = FDFDocument.loadXFDF(is)
{code}
and afterwards the same documet is saved via
{code}
fdfDocument.saveXFDF(...)
{code}
the output document contains only empty fields. The problem is that
{code}
FDFField(Element fieldXML)
{code}
creates with "setValue" not a "COSString", what is expected by "getValue", when
saving the document.
FDFField should use
{code}
setValue(new COSString(XMLUtil.getNodeValue(child)));
{code}
to create correct values for the XML nodes. Otherwise the import of FDF
documents via e.g.
{code}
pdAcroForm.importFDF
{code}
does not work correct.
Patch for 2.0.3 is attached.
--
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-3322) Warning "You did not close a PDF Document" when visual signature is added
[
https://issues.apache.org/jira/browse/PDFBOX-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Engelhardt updated PDFBOX-3322:
-
Attachment: addSignatureFix.patch
We encountered a problem which may be related to this.
As we are adding (/creating) signatures in one method and are saving the
created document in another method, we do leave the scope in which we defined
the SignatureOptions object. We did not realize, that the SignatureOptions
class is closeable, so we did neither store it's instance (thus preventing
garbage collection until we want to terminate it.) nor did we take other
measures to ensure, that the COSDocument and it's substructures will not be
terminated before the document has been saved.
First of all: Thanks for clearing things up! I read through your comments and
was able to understand what we were doing wrong and how it could be fixed...
However - as the existing solution is already providing a fallback for users
who don't close documents, we would suggest to expand that approach. (We
actually do close PDDocuments actively - but didn't realize we would have to in
this case)
Summary: If a visual signature is added and the temporary COSDocument of the
SignatureOptions instance is garbage collected before saving the document, this
will result in corrupted files/exceptions. If however the PDDocument - the
Signature is added to - would clone the COSObjects of the temporary COSDocument
such errors would be prevented entirely.
You could argue, that we caused the problem in the first place, by not
realizing that SignatureOptions is implementing the Closeable interface and
handling it accordingly - but I expected a class containg the term "Options" in
it's name, would rather be some kind of POJO or simple property container,
instead of managing resources aswell... It does feel counterintuitive to a
certain extend.
We want to make a suggestion by providing a small two line patch, which does
clone the substructures of the temporary COSDocument and thus prevents such
errors. When applying this patch, the local options container (Method:
"addSignature(PDSignature sigObject, SignatureInterface signatureInterface,
SignatureOptions options)" Class: PDDocument) may theoretically be closed
directly after calling "prepareVisibleSignature(signatureField, acroForm,
visualSignature)". If that thought was expanded upon and the temporary
COSDocument was removed from the SignatureOptions class, it would not have to
be a Closeable anymore, plus the management of the temporary COSDocument and
resulting pitfalls (such as the one we encountered) would be removed.
Keep up the good work!
> Warning "You did not close a PDF Document" when visual signature is added
> -
>
> Key: PDFBOX-3322
> URL: https://issues.apache.org/jira/browse/PDFBOX-3322
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel, Signing
>Affects Versions: 1.8.11
>Reporter: Petras
>Assignee: Tilman Hausherr
> Labels: signature
> Attachments: addSignatureFix.patch,
> PDFBOX_3322_VisualSignatureClosing.patch
>
>
> When visual signature is added, warning "You did not close a PDF Document" is
> added to the output log. It appears, that _VisualSignatureParser_ creates an
> instance of _COSDocument_ and later is held by _SignatureOptions_, but for
> this instance the {{#close()}} method is never called, which results to that
> warning reported by its {{#finalize()}} method.
> Probably it should by closed by _PDDocument_ when used after signing.
--
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
