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.
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
back to new as the patch was abandoned due to license issue.
(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
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
(In reply to Kevin Suo from comment #4) Anybody else is welcome to do implement this as I am quite new to c++ and am still learning.
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.
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...
I'll give it a try.
Just to give a status update, I'm about half-way complete on making the code change. I need to finish that and write up some unit tests before I can submit a patch.
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.
*** Bug 146187 has been marked as a duplicate of this bug. ***
*** Bug 114840 has been marked as a duplicate of this bug. ***
*** Bug 142312 has been marked as a duplicate of this bug. ***
*** Bug 143472 has been marked as a duplicate of this bug. ***
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.
*** Bug 155042 has been marked as a duplicate of this bug. ***