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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Version: 5.1.0.2 Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc CPU Threads: 4; OS Version: Linux 3.13; UI Render: default; Locale: en-GB (en_GB.UTF-8) The problem is still present in 5.1.0.2, for the PDF password entry. However the CONFIRM password field does allow the use of special characters. So whereas only ace is valid in the password entry field, aceáçé is valid in the password confirmation field. The help entry includes the text "Contains a mix of lower-case and upper-case letters, numbers, and special characters." which appears to confirm that it is a bug.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Issue still exists. Tested with 5.2.7.2 on Gentoo Base System release 2.3 x86_64
The PDF encryption was implemented here: https://bz.apache.org/ooo/show_bug.cgi?id=12626 Code pointers: 1. Setting the password dialog to only accept ASCII: > aPwdDialog->AllowAsciiOnly(); in IMPL_LINK_NOARG(ImpPDFTabSecurityPage, ClickmaPbSetPwdHdl, Button*, void) (filter/source/pdf/impdialog.cxx) 2. Using the string encoded as ANSI-1252: > OString aString( OUStringToOString( i_rPassword, RTL_TEXTENCODING_MS_1252 ) ); in void PDFWriterImpl::padPassword( const OUString& i_rPassword, sal_uInt8* o_pPaddedPW ) (vcl/source/gdi/pdfwriter_impl2.cxx) 3. Code that checks if an allowed character is entered: void SfxPasswordDialog::ModifyHdl(Edit* pEdit) (sfx2/source/dialog/passwd.cxx) I am now unsure if it would be good idea to make both fields (password and verification) working identically: if they both filtered user input, then user could not notice that some of characters were rejected, and be sure that the password is as entered; and after that, would discover the password (containing non-1252 characters) be wrong. But anyhow, the code that filters out characters could make visual and audible hints that some characters got filtered (e.g., balloon hints or something). The other idea (to use UTF-8 encoding, and thus allow any input) looks more appealing.
The relevant information from Adobe is here: https://forums.adobe.com/thread/831473 https://forums.adobe.com/thread/489152 So, the algorithm used by LibreOffice could in theory allow using any characters, but they would need to be converted to system 8-bit codepage (different for Win and Mac) before using for encryption. Thus, a PDF encrypted with non-ASCII characters would be ~impossible to open on any system with different system locale. Thus, using the ASCII restriction is a good choice. I tested that encoding the password as utf-8 makes the PDF unopenablw using Adobe Acrobat Reader DC 2017. The problem here remains only to make this user-visible and documented. As the easiest solution for those who would like to implement this (as an easyhack), I'd propose to add to the SfxPasswordDialog a (yellow?) label saying something like "Only English letters, numbers other ASCII characters", which were hidden by default, and were made visible in the SfxPasswordDialog::AllowAsciiOnly().
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still repro with Version: 6.1.0.1 (x64) Build ID: 378e26bd4f22a135cef5fa17afd5d4171d8da21a CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL
Looks like a dupe of 50400. Please explain if not. I'll copy some of Mike's comments there. *** This bug has been marked as a duplicate of bug 50400 ***