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
Fixed by 2bbe15a2cea20d2dfb9346992a9bf8ff39b4d42c.
(In reply to Mike Kaganski from comment #30) > Fixed by 2bbe15a2cea20d2dfb9346992a9bf8ff39b4d42c. Let me clarify. Quoting the current summary of the issue: > PDF: LO allows editing write-protected PDF when password field empty or clicking "Cancel" This was set in comment 24 by stragu, with the stated rationale: > a PDF viewer opening the file is not a bug, but being able to edit the file > without giving the correct password is. Which is not correct. We do not edit PDFs. We have PDF only in Export dialog, not in Save (As); and that basically means, that application tells to users, that they import a PDF as Draw document, but when export the Draw document as PDF, they create a completely new document, unrelated to the original one - if it has the same name, it simply drops the old, and creates new. We do *not* claim we edit PDFs. If needed, we may want to emphasize it in the UI, but that is what it is. And additionally, *if* we ever make PDF filter the first-class filter, i.e. move it from export to save (as): then we need to treat the save protection the same way as we do for ODF. Save an ODF with only a password for editing (open file read-only + pw; no open password = no encryption), then open it. It will not ask any passwords on opening, and will just set the UI to read-only; this is what would have to happen here as well. The fix mentioned above just removed incorrect prompt, which was shown incorrectly - LibreOffice detected *a* protection, and assumed it needed to ask for password, and now it tests empty password from start, as it should. It completely resolves the original stated problem. So: restoring the original summary. Anything else needs own reports.
> 5. After password entered LO not able to open the file even after Cancel - it says "General IO error" My whole point was to avoid this error. If libreoffice can open encrypted PDF without asking for a password it's even better. I hope the fix also fixes the case of "General IO error" when incorrect password is entered.