While trying to export a PDF from LO-Writer, i encountered that the first textfields to set a password to either open the document or to have write access, doesn't accept the letter §. The second textfield, to confirm the typed in password, accepts the character §, leading to a "false password". Ways to reproduce: 1.) Select 'Export to PDF' from the File menu dialog. 2.) Navigate to 'Security'-tab. 3.) Typ in character § in the first textfield of each option. This issue has been present in LibreOffice > 4.1.2.3 (unsure if inherited from OOo)
Reproducible with 3.3.0.4-4.1.2.3 and AOO 4.0. Actually, a number of characters are not accepted in the first field: I tested § (in Windows, key combination Alt+0167), as well as © (Alt+0169).
reproducible under Win7x64 using OOo 3.3.0, LibO 4.3.2.2 and 4.4.0.0.alpha1+ Build ID: 6ba8b7f5eacac969e4781d63718083a05491b1bc TinderBox: Win-x86@42, Branch:master, Time: 2014-10-24_02:23:51 there are multiple characters not allowed... here's the list I've found: £ ì è é ò ç à ° § ù © edited summary notes and set version to "inherited from OOo"
Also reproducible with 4.3.2.2 under Ubuntu 14.04.
Same problem with 4.3.2.2 and ubuntu 12.04. It looks as if the password has to be US-ASCII (7bit)and not the normal Unicode. The Characters £ ì è é ò ç à ° § ù © etc are in ISO-8859-1 (Western European 8 -bit). Is this a PDF password restriction?
(In reply to Peter Maunder from comment #4) > Is this a PDF password restriction? PDF spec (http://www.adobe.com/devnet/pdf/pdf_reference.html) does not impose any restriction on the password string. It references RFC 2898 (https://www.ietf.org/rfc/rfc2898.txt), which itself specifies: > Throughout this document, a password is considered to be an octet > string of arbitrary length whose interpretation as a text string is > unspecified. In the interest of interoperability, however, it is > recommended that applications follow some common text encoding rules. > ASCII and UTF-8 [27] are two possibilities. (ASCII is a subset of > UTF-8.) So, there seems to be no special reason not to use internationalized characters in passwords. Taking into account that PDF standard provides for 32-byte passwords only, using non-ASCII (multi-byte) may somewhat weaken the security, but this should be up to user (probably with warning). However, there must be some convention somewhere regarding this, so that different PDF readers could encode passwords coherently. I haven't found this convention yet. Still, even if there is ASCII-only password restriction, there should be (1) notice in the password dialog (so that user would not enter some characters looking at the keyboard, not at screen, and the absent characters would be unnoticed), and (2) coherent behaviour of both "enter password" and "confirm password" input boxes.
(In reply to Mike Kaganski from comment #5) > Is this a PDF password restriction? No should allow Unicode UTF-8. I agree with your comments. If it is a genuine restriction the restrictions should be stated clearly on the password panel. If not it appears to be a bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.