When recovering an encrypted document, LibreOffice asks for the password to decrypt the original, then "forgets" that is encrypted. Subsequently saving the document saves it without encryption, without warning. This can very easily lead to silent stripping of the password on the recovered document, which will go un-noticed unless/until the user subsequently opens the document and also realises that they were not asked for a password. I'm assuming that when LO opens an encrypted document it caches the password for subsequent saving; in this case it should be possible to also cache at the point of opening/decrypting the original during recovery. Given that this results in silent loss of encryption I have set the issue severity to major.
Hi, can you provide a sample corrupted document (and its password) so we can make some tests with it and what is your operating system. Thanks, setting as needinfo - Sophie
I ran a set of tests against different document types, and this actually only affects OOXML documents. Steps to reproduce: * Start Calc (or Writer, etc.) * Under Options -> Load/Save -> General, make sure "Save AutoRecovery information" is checked, and "Automatically save the document" is unchecked (these were the defaults already for me) * Change auto-recovery interval to 1 minute (for speed of reproduction) * Save the document with encryption as .xlsx (or .docx, etc.) * Close the document, and completely quit LibreOffice * Open the document * Make a change * Wait at least 1 minute * Force-kill the soffice.bin process (on Linux: pkill -9f soffice.bin) * Start Calc (or Writer etc.) * Complete document recovery * Make a change * Save the document (Ctrl-S or click the save icon) * Close the document * Open it again The document no longer has a password.
** 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
Still present, 5.2.7.2
This bug was never confirmed by a person different than the reporter. Moving it back to UNCONFIRMED
Sorry, that's ridiculous. This bug is not intermittent and its reproduction is not difficult, time-consuming or lacking a full set of steps. I provided clear, step-by-step instructions to reproduce this two years ago, which take approximately *two* minutes for anyone to carry out to confirm this. I have since *re-tested* it two years later using my *exact* instructions, on an entirely different system, and re-confirmed it. To further eliminate any doubt, I have now re-tested it a *third* time, and re-confirmed it again, using a fresh VM and a Fedora 26 live ISO. This makes the bug environment *exactly* reproduceable, and clearly not even slightly custom. I am changing the status back to new. Instead of changing it again, either take the two minutes needed to actually confirm it, or leave the status as new. Setting it to UNCONFIRMED is an abuse of that status on the technicality that no-one has bothered to even *try* to confirm the easily and quickly reproduceable bug, which would actually be the useful thing to do.
I'm sorry but you can confirm your own bugs. Setting to UNCONFIRMED until some else confirms it.
I guess you meant to say "can't", and I'd be embarrassed in your situation to be wasting time on counter-productive technicalities instead of spending two minutes to confirm the bug, since you have enough time to write a response in the first place. Setting back to NEW. Please think really hard about if you really think it helps ANYONE to keep setting this back to UNCONFIRMED. There are two possibilities here: 1. I'm a pathological liar, and this bug doesn't exist/I haven't taken the time to eliminate any doubt about its existence on completely vanilla, reproduceable setups 2. This is actually a real bug, and for all practical purposes, it has been confirmed, three times. Arguing about this and repeatedly setting it to UNCONFIRMED helps exactly *no-one*.
And just as a reminder: * this is a serious document security issue - it SILENTLY strips document encryption following an application crash
*** Bug 116327 has been marked as a duplicate of this bug. ***
The dup allowed to confirm this one. Let's increase the importance given the security problem it indeed brings.
> The dup allowed to confirm this one. The list of steps to reproduce has been on this bug since September 2015. It never needed another reporter to confirm the issue.
(In reply to documentfoundation from comment #12) > > The dup allowed to confirm this one. > > The list of steps to reproduce has been on this bug since September 2015. > > It never needed another reporter to confirm the issue. Wrong, see comment 7.
> Wrong, see comment 7. Not wrong, what it actually needed was anyone else to run through the listed steps to confirm it, which takes ~2 minutes. I completely understand *why* there is the principle of "you can't confirm your own bug", however, that should *only* be applied as a principle *if* it's ***not*** reproducible, otherwise it's just deck-chair rearranging. No-one even tried to reproduce it. In addition, per comment 6, I even went to the effort of testing this in a fresh VM to eliminate personal system config. and re-verify reproducibility. Blindly applying rules when there's actually an intelligent/useful/obvious/quick alternative action helps no-one. This is pretty obvious from the fact that this bug languished for 2.5 years because e.g. Xisco chose to quote a rule rather than run through the steps, and there has been a serious document security problem that only *now* has been raised in importance.
Do I need to file a CVE on this for it to get attention it deserves a potential security issue?
Dear DN, 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 exists in 6.3.2.2.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd198398b6e5c84ab1255a90ef96e6445b66a64f tdf#93389: keep encryption information for autorecovered MS formats It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 129096 has been marked as a duplicate of this bug. ***
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/2cd3632ac93169ad3c082ff4fb740c3d3dfff071 tdf#93389: keep encryption information for autorecovered MS formats It will be available in 6.4.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/b6809c72b509fcc223c80595d554902a1b4f4e24 tdf#93389: keep encryption information for autorecovered MS formats It will be available in 6.3.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Problem is still reproducible with scenario from https://bugs.documentfoundation.org/show_bug.cgi?id=129096 Tested with master on Win10.
(In reply to Vasily Melenchuk (CIB) from comment #22) > Problem is still reproducible with scenario from > https://bugs.documentfoundation.org/show_bug.cgi?id=129096 Just tested with Version: 7.0.0.0.alpha0+ (x64) Build ID: d2dfda8aba7701d19001d7a080d965a83e30443f CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL and couldn't repro. Created an empty doc in Writer; saved it with password "1" as DOCX; reopened to make sure it asks for the password; entered a word; let it wait an auto-save; killed soffice.bin using task manager; started soffice and got a recovery prompt; agreed and was asked the password; entered the password and got successful recovery with the entered word; pressed Save button and was asked to confirm saving as DOCX (no password prompt); saved and reopened => it asked for the password.
Aha, see it when not waited for autosave.
Yes, without autosave LO still losing password. I have ugly hack for this situation https://gerrit.libreoffice.org/c/core/+/84039 But have no good ideas how to improve it.
tdf#129096 is fixed in a separate way. Returning this task to RESOLVED state
*** Bug 118011 has been marked as a duplicate of this bug. ***