Created attachment 61296 [details] The file requiring password. I'm using latest git. Problem description: Steps to reproduce: 1. Open attached file with libreoffice Current behavior: 1. Open attached file with libreoffice 2. LO asks for password: see attached screenshot-1.png 3. Pressing Cancel successfully opens a file. 4. Entering something says: incorrect password 5. After password entered LO not able to open the file even after Cancel - it says "General IO error" Expected behavior: Evince displays the file with no password required, also selecting "Cancel" in LO successfully opens the file. I expect the file to be opened without password. Also, if the file is indeed protected somehow, i expect LO to provide more information about what is happening. Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/10.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Created attachment 61297 [details] Password dialog
(In reply to comment #0) Confirmed here and I couldn't find a duplicate: Version 3.6.0.4 (Build ID: 932b512) Slackware Linux 13.37 If there is no password assigned, why would the password dialog appear in the first place?
Could it be write-protected PDF? Then LO in fact is asking for password for write access? Meaning evince does not require any password for read-only access. Even if this is true, the dialog text is misleading, it says "Enter password to _open_ file:" while in case write-protected file it should say something like "Enter password to open file for modification or press Cancel if you want it open read only".
The password dialog appears because the PDF file is encrypted, pdfinfo says: Encrypted: yes (print:yes copy:yes change:no addNotes:no) Which means printing and copying is enabled without password, changing the PDF or adding notes is forbidden.
Reproducible with LibreOffice 4.2.5 and 4.3.0 on debian. > The password dialog appears because the PDF file is encrypted Anyway, "General IO error" is not correct behavior.
** 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.0.5 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 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
This issue is still reproducible with the current GIT build.
Created attachment 124944 [details] Document security as shown by Acrobat Reader XI In fact the document is read-only. 1. Change the text to something like "Enter password for write-protected file...". 2. Make sure that cancel aborts the processing. Right now (5.2 alpha) it's possible to edit the write protected document after canceling. Looks like an EASYHACK.
Changing to NEEDING - Please supply a code pointer (mandatory for easyHacks) - Please supply skill* and difficulty* keywords
Removing keyword 'needsDevEval' as this bug is an easyHack
Changing status: NEEDINFO -> NEW Adding keyword 'needsDevEval' [ninjaedit]
Removed easyHack since this bug doesn't seem to have been evaluated properly to be tagged as such and missing code pointers. For a start a re-evaluation from QA to see if this issue is still standing would help.
(In reply to Shinnok from comment #12) > Removed easyHack since this bug doesn't seem to have been evaluated properly > to be tagged as such and missing code pointers. > > For a start a re-evaluation from QA to see if this issue is still standing > would help. Sure but please do not request further input from UX when it has been done :-)
Bug still there in LO 6.0.0.1 / Windows 7. Adjusting earlier version, since bug is already in 3.3.0. File also opens much slower in 6.0.0.1 than in 3.3.0.
still repro in Version: 6.1.0.0.beta2+ (x64) Build ID: fe1a23b5c49c94410a604c8d4a6f50f43d575403 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:libreoffice-6-1, Time: 2018-06-17_06:31:41 Locale: ru-RU (ru_RU); Calc: CL
Dear Sergey, 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
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
Created attachment 170474 [details] bt with debug symbols Here's a bt when password dialog box displays.
*** Bug 142311 has been marked as a duplicate of this bug. ***
Created attachment 172308 [details] A PDF file encrypted using empty password a demo PDF encrypted using empty password via qpdf
The problem is that the file is encrypted using empty password. - Try to open the file with Draw and enter any string. You will get: "The password is incorrect. The file cannot be opened." - Delete the string making the password field empty and press OK. The file is opened. The password is null. I have many financial statements that are encrypted using empty password. There are reasons, mostly relevant for Adobe products, for using empty passwords. I I also attached a demo PDF encrypted with empty password via qpdf. Programs such as Adobe Reader, Chrome / Chromium, Firefox, Evince, Okular, GIMP, and ImageMagic, and others don't prompt for password when the password is null. Even programs which has problems with PDF decryption such as Imagemagic and Inkscape silently open such files.
(In reply to yury.dubinsky from comment #21) > There are reasons, mostly relevant for Adobe products, for using empty > passwords. If you wouldn't mind, could you elucidate more what those reasons are? I can't think of any, but I don't use much Adobe products any more.
I guess I know one reason. Let’s examine the example from this post using pdfinfo. We see: Encrypted: yes (print:yes copy:yes change:no addNotes:no algorithm:RC4) 2/3 of my financial statements received from credit card companies and banks have this encryption level and are also encrypted with blank passwords. When addNotes is no, Adobe Reader, which is the standard for all financial businesses, does not support annotations in these PDFs. Of course, it is a funny protection, but security departments need their food.
Changing summary to be more accurate as a PDF viewer opening the file is not a bug, but being able to edit the file without giving the correct password is. Also confirmed on: Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 148457 has been marked as a duplicate of this bug. ***
I don't consider this a bug. LO works more like OCR than PDF editor. Any OCR will render password useless. If someone tries to open that PDF in LO, he obviously wants to edit it, why restrict that and say "look for some other app".
(In reply to Timur from comment #26) > I don't consider this a bug. LO works more like OCR than PDF editor. Any OCR > will render password useless. If someone tries to open that PDF in LO, he > obviously wants to edit it, why restrict that and say "look for some other > app". Not a bug? I don't think so, then why LO ask for a password in the first place? Then allow user to enter and edit the file with blank password or just hit cancel? There must be something wrong with the work flow! :)
(In reply to stragu from comment #24) > Changing summary to be more accurate as a PDF viewer opening the file is not > a bug, but being able to edit the file without giving the correct password > is. > > Also confirmed on: > > Version: 7.2.6.2 / LibreOffice Community > Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 > CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded I agree on this! Is it possible to work this way? If wrong password, then user has the option to open the file with set permission as per creator set if not, then block.
Dear Sergey, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug