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
/CFM /AESV2 >> >>
/StmF /StdCF >>
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: 18.104.22.168.alpha2+
Build ID: c989f5e0e11e295b11ffc921b0d105869e037e47
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-07_22:50:48