Bug 55425 - PDF import: support encryption algorithm value 4 (AES)
Summary: PDF import: support encryption algorithm value 4 (AES)
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: All All
: medium enhancement
Assignee: Michael Warner
URL:
Whiteboard:
Keywords:
: 114840 142312 143472 146187 155042 (view as bug list)
Depends on:
Blocks: PDF-Import-Draw Password-Protected
  Show dependency treegraph
 
Reported: 2012-09-28 15:06 UTC by Stephan Bergmann
Modified: 2023-11-24 15:55 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Bergmann 2012-09-28 15:06:20 UTC
For example, the .pdf file attached to <https://bugzilla.redhat.com/show_bug.cgi?id=826526> "cannot import pdf 1-5 format with encrypted sections in otherwise unprotected document" (as <https://bugzilla.redhat.com/attachment.cgi?id=587716>) contains an Encrypt dictionary of

10747 0 obj
<< /Length 128
   /CF << /StdCF << /Length 16
                    /AuthEvent /DocOpen
                    /CFM /AESV2 >> >>
   /Filter /Standard
   /O (...binary...)
   /P -1052
   /R 4
   /U (...binary...)
   /V 4
   /StrF /StdCF
   /StmF /StdCF >>
endobj

whose V entry 4 specifies an en-/decryption algorithm that makes use of the CF, StmF, and StrF entries.  This was introduced with PDF 1.5 (for reference, see Table 20 "Entries common to all encryption dictionaries" in section 7.6.1 of <http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf> "Document management — Portable document format — Part 1: PDF 1.7").

But our import code currently only supports older algorithm values 1 and 2 (cf. "m_pData->m_nAlgoVersion > 2" in PDFFile::setupDecryptionData at <http://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/pdfparse/pdfentries.cxx?id=eecaca80bdcf9060a5dd06a835a2c1752b4fec01#n1235>).  The resulting effect is that LO keeps asking for a password to open the document (bAuthenticated can never become true in the loop in checkEncryption at <http://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/wrapper/wrapper.cxx?id=eecaca80bdcf9060a5dd06a835a2c1752b4fec01#n944>).

So, it would be nice if we also supported algorithm value 4.
Comment 1 Buovjaga 2014-11-08 15:02:32 UTC
I confirm that it can't be imported. Sounds like a good enhancement.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: c989f5e0e11e295b11ffc921b0d105869e037e47
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-07_22:50:48
Comment 2 Kevin Suo 2021-11-22 11:23:41 UTC Comment hidden (obsolete)
Comment 3 Michael Warner 2021-11-23 14:26:11 UTC
(In reply to Kevin Suo from comment #2)
> back to new as the patch was abandoned due to license issue.

Patch referred to here was this:
https://gerrit.libreoffice.org/c/core/+/124909
Comment 4 Kevin Suo 2021-11-23 15:29:11 UTC
A better approach is to add a --mode checkEncryption in the out-of-process xpdfimport binary in 
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx?r=648e4106

It should be called like this:
./xpdfimport --mode checkEncryption filename
./xpdfimport --mode checkEncryption -upw 123456 filename

it should return 0 if the file is not encrypted, or return 0 if file is encrypted and the password upw is correct.

it should exit(1) or any other error code, or print a message, if the file is encrypted but no password is provided or wrong password.


then call this to replace the encryption check in
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/wrapper/wrapper.cxx?r=8b9e5024#1021

here, we first call the xpdfimport in checkEncryption mode without a password. If the process return code 0 then go on with the following osl_executeProcess_WithRedirectedIO process call in normal mode, otherwise call getPassword as shown in
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/wrapper/wrapper.cxx?r=8b9e5024#928
until checkEncryption mode returns 0 or user cancels password input
Comment 5 Kevin Suo 2021-11-23 15:31:04 UTC Comment hidden (obsolete)
Comment 6 Michael Warner 2021-11-24 15:23:28 UTC
I recommend against providing the password as a command-line argument, because other processes can access it that way. For a demonstration of this you can run either Linux top or Windows Task Manager and show the Command Line column.
Comment 7 Kevin Suo 2021-11-24 15:30:40 UTC
Then we need to provide the password via the stdin (pIn) of the process. I tried but failed, xpdfimport hangs there because pIn is true while there is no stdin provided at the beginning. Maybe someone else can take a try...
Comment 8 Michael Warner 2021-11-30 03:49:58 UTC Comment hidden (obsolete)
Comment 9 Michael Warner 2022-01-07 14:46:34 UTC Comment hidden (obsolete)
Comment 10 Michael Warner 2022-05-11 13:05:42 UTC
I continue to spend a few minutes on it here and there as I get time, but I admit progress on this has been slow. I have many other interests and obligations in life and LO just isn't at the top of the list. If someone else wants to take this on, I'm fine with uploading what I have for them to use. Otherwise, I will continue grinding away, on my own schedule.
Comment 11 Timur 2022-07-06 10:10:48 UTC
*** Bug 146187 has been marked as a duplicate of this bug. ***
Comment 12 Timur 2022-07-06 10:44:18 UTC
*** Bug 114840 has been marked as a duplicate of this bug. ***
Comment 13 Timur 2022-07-06 12:16:59 UTC
*** Bug 142312 has been marked as a duplicate of this bug. ***
Comment 14 Timur 2022-07-06 12:19:02 UTC
*** Bug 143472 has been marked as a duplicate of this bug. ***
Comment 15 Michael Warner 2023-01-03 04:55:42 UTC
Just as a status update on this, I have some initial code written, but I am still testing and debugging it. I also will need to write some regression tests for it, once I have it working interactively.
Comment 16 Timur 2023-11-24 15:55:11 UTC
*** Bug 155042 has been marked as a duplicate of this bug. ***