Apache OpenOffice (AOO) Bugzilla – Issue 90373
pdf generated with unicode password could not be opened
Last modified: 2017-05-20 10:29:16 UTC
The exported PDF files protected with unicode passwords could not be opened. Tested with two readers: Adobe Reader 9.0 and Foxit Reader 2.6 on Windows. Password for testing: ěšÄřžýáÃé (9 characters)
Known problem, the problem is that in the PDF reference there is no encoding for the password specified, only that it should be paded to 32 bytes. The only thing that we know to work is ansi1252 (or respectively iso8859-1), therefore the password is converted to that encoding. Meaning your string afterwards probably was "?????????" since unconvertible characters are replaced by '?'. To solve this problem we need to find out which encoding acrobat reader would accept.
Could we simply limit password characters to ASCII until we know the encoding?
That is effectively happening; the password is converted to ansi1252 encoding (aka iso8859-1). Limiting the entry at the dialog would indeed be preferable, alas this is currently not possible since that is a general purpose dialog used for passwords everywhere.
Created attachment 65539 [details] PDF with a non-ascii password "Ä…Äęėįšųūž"
Attached above is a PDF file with password "Ä…Äęėįšųūž" set using Adobe Acobat software. Perhaps it's possible to reverse engineer the encoding scheme used for it?
My acrobat reader (mac, 9.2.0) doesn't even open the attached file with that password. So I guess that unicode passwords indeed are rather undefined.
->pl: I hope you entered the password without quote characters? It works on Windows for me. I'm downloading Linux version right now to check on it too. BTW, if I export a PDF from OpenOffice, and use password "Ä…Äęėįšųūž", I cannot open it with Reader even if I enter "?????Å¡??ž". So, the current scheme seems to be really buggy to me. If it's impossible to limit characters from within the dialog box, then perhaps it's possible to trigger an error dialog if the password contains non-ascii characters?
No, I didn't copy the quotes
Funny. The Reader on Linux doesn't allow me to enter any of those characters except "ž" and crashes right away if I submit a password containing this letter. :) BUT ONLY IF I'M USING KEYBOARD TO ENTER IT! If I paste the password instead, it says the password is incorrect, just like it does to you, and does not crash. ->pl I really can't believe that it's impossible to check input while it's being entered (onChange) and act accordingly. But if it really is, then OOo should at least check the password before saving the PDF, and if the password contains anything but ASCII (or windows-1252), OOo should return to the same dialog instead of saving.
The latest Adobe supplement to the PDF reference at least specifies that the password should be converted to PDFDocEncoding. Which is only partially helpful since PDFDocEncoding is a single byte encoding, also, so the conversion problems remain. Oh well. I guess the optimal solution would indeed be to modify SfxPasswordDialog (which is used to enter the password) so it does not accept non ascii input.
Would the modification of SfxPasswordDialog only affect PDF export or something else too?
SfxPasswordDialog can now optionally forbid non-Ascii characters. Since it seems that even Adobe cannot reliably work with non-Ascii passwords, it seems best to forbid them while entering. Fixed in CWS vcl106
->pl Could this be backported to 3.2?
Technically no problem. However you would have to convince releases@openoffice.org that this is a showstopper.
please verify in CWS vcl106
Verified with cws vcl106 = OK; Non-Ascii characters are forbidden now.