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. ***
Created attachment 195131 [details] incomplete feature branch bundle Bundle of my feature branch rebased on master. It doesn't work, I didn't even try to build it after rebasing.
I'm unassigning myself, because I might as well face it, I'm never going to finish this. I attached a bundle with what I got in case anyone else wants to pick that up. But it doesn't completely work.
(In reply to Michael Warner from comment #17) > Created attachment 195131 [details] > incomplete feature branch bundle > > Bundle of my feature branch rebased on master. It doesn't work, I didn't > even try to build it after rebasing. I tried cloning it inside libreoffice repo, but it fails: $ git clone tdf55425.bundle Cloning into 'tdf55425'... hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name> error: Repository lacks these prerequisite commits: error: 2ad7d5cfb0288559921b0d9ccad0a23d95cde452 fatal: remote transport reported error
Created attachment 195156 [details] Patch file created from changes provided by Michael I could open the above .bundle file using: $ git bundle unbundle tdf55425.bundle Unbundling objects: 100% (35/35), 6.89 KiB | 3.45 MiB/s, done. Resolving deltas: 100% (23/23), completed with 9 local objects. f86d04014c0149c7df81d582cfc1cc9b43fe2807 refs/heads/tdf55425_pdf_encryption_4 $ git show f86d04014c0149c7df81d582cfc1cc9b43fe2807 > tdf55425.patch
Created attachment 195157 [details] Patch file created from changes provided by Michael I could open the above .bundle file using: $ git bundle unbundle tdf55425.bundle Unbundling objects: 100% (35/35), 6.89 KiB | 3.45 MiB/s, done. Resolving deltas: 100% (23/23), completed with 9 local objects. f86d04014c0149c7df81d582cfc1cc9b43fe2807 refs/heads/tdf55425_pdf_encryption_4 $ git show f86d04014c0149c7df81d582cfc1cc9b43fe2807 > tdf55425.patch
Created attachment 195158 [details] Patch files created from changes provided by Michael I could open the above .bundle file using: $ git bundle unbundle tdf55425.bundle Unbundling objects: 100% (35/35), 6.89 KiB | 3.45 MiB/s, done. Resolving deltas: 100% (23/23), completed with 9 local objects. f86d04014c0149c7df81d582cfc1cc9b43fe2807 refs/heads/tdf55425_pdf_encryption_4 One can cherry pick 4 commits from f86d04014c~3 to f86d04014c on top of master. The attached zip file contain all of them, and also squashed in a single file.