Description: please consult the rest of the report. thank you Steps to Reproduce: 1.save as -> docx and select "save with password" -> the resulting file can be opened with the given password 2. save as -> docx "save with password" NOT checked -> the resulting file can only be opened with the password even though it should be possible to open it without one 3. Actual Results: once a docx file was saved with a password it can afterwards only be opend with a password, even when this option was not selected in the "safe as ..." - dialogue any more Expected Results: since no password was selected, the file should just open without requiring to enter one Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta1 Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: de-AT (de_AT.UTF-8); UI: en-US Calc: threaded using odt file format a file can be saved without a password after saving it with one
On pc Debian x86-64 with master sources updated today, I could reproduce this. Mike: noticing https://cgit.freedesktop.org/libreoffice/core/commit/?id=dd198398b6e5c84ab1255a90ef96e6445b66a64f tdf#93389: keep encryption information for autorecovered MS formats The autorecovery data is stored in ODF, regardless of the original document format. When restoring, type detection generates ODF data, which is stored in the media descriptor attached to document, even after real filter was restored (see AutoRecovery::implts_openDocs). If real filter is not ODF, then at the save time, it doesn't find necessary information in encryption data, and makes not encrypted package. ... thought you might be interested in this one.
(In reply to Julien Nabet from comment #1) It's a regression in 7.0 - possibly related, but still bibisect could help.
(In reply to Mike Kaganski from comment #2) > (In reply to Julien Nabet from comment #1) > > It's a regression in 7.0 - possibly related, but still bibisect could help. Thank you Mike for your feedback. I never did bibisect and reading doc about it, it seems to me a long way to retrieve what it needs + quite tedious to do the bad/good process. I can't help here=>uncc myself.
This started with the following commit, bibisected using repo bibisect-linux-64-7.0. A notable difference in the Save dialog is that prior to this commit 'Save with password' is ticked when you attempt to 'Save as' the existing password-protected DOCX, while after this commit it's unticked, yet the file is saved with a password. Adding CC: to Vasily Melenchuk. https://cgit.freedesktop.org/libreoffice/core/commit/?id=e0cced9d4c94324e834e46d807469a0cd6c1f738 author Vasily Melenchuk <vasily.melenchuk@cib.de> 2019-10-14 00:01:52 +0300 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-11-15 12:50:38 +0100 do not clean up EncryptionData during SaveAs
Aww, I bibisected this at the same time... shame you were not on IRC as I announced it.
(In reply to Buovjaga from comment #5) > Aww, I bibisected this at the same time... shame you were not on IRC as I > announced it. Nevermind, it was browser cache betrayal :(
*** Bug 135582 has been marked as a duplicate of this bug. ***
Does anyone know of a workaround how to disable password protection after this bug?
*** Bug 136116 has been marked as a duplicate of this bug. ***
(In reply to Aron Budea from comment #8) > Does anyone know of a workaround how to disable password protection after > this bug? IIUC, the only workaround is to use a previous version.
*** Bug 136480 has been marked as a duplicate of this bug. ***
I happens also wit ods format.
IMO, it has a higher importance (makes certain functionality not working, with no workaround in affected version - "don't use broken version" is not a workaround that can be considered when talking about a bug's importance/severity).
(In reply to Aron Budea from comment #8) > Does anyone know of a workaround how to disable password protection after > this bug? The documents can be opened and the password removed by using a different office suite. This was sccessfully tested with OpenOffice 4.1.7 and a recent version of Microsoft Office. People may not like this suggestion out of ideological considerations, which I understand, but it was pretty helpful for me and may help others as well to access their work.
*** Bug 137194 has been marked as a duplicate of this bug. ***
> Timur <gtimur@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords| |filter:docx ... but see comment 12.
*** Bug 136697 has been marked as a duplicate of this bug. ***
*** Bug 136750 has been marked as a duplicate of this bug. ***
*** Bug 137052 has been marked as a duplicate of this bug. ***
*** Bug 137240 has been marked as a duplicate of this bug. ***
*** Bug 137237 has been marked as a duplicate of this bug. ***
*** Bug 137254 has been marked as a duplicate of this bug. ***
(In reply to Mike Kaganski from comment #10) In reference to a work around: I don't know if that is important, or relevant. And I just tried it once, some time ago. It worked, but I might be wrong in the details as I write it now. On Linux, one have a password protected document that is opened by LibreOffice. In order to have a copy of the document without password protection, copy the whole document to the clipboard. That is, select all (Ctrl A), and copy (Ctrl C). And then pasting to an entirely new document (File -> New). The new document can be "Save As..." (or did I exported... it?) without being password protected.
*** Bug 137309 has been marked as a duplicate of this bug. ***
*** Bug 137388 has been marked as a duplicate of this bug. ***
additional to this bug: this is not only present as "save as *.docx" but unfortunately even is storing the document as *.odt. so, once a password has been set when saving - unfortunately it cannot be removed. Critical! Try: create a new Writer Document - edit some text -> Save with Password -> colse Document. Reopen Document - > enter PW. Change something or just save it as new -> create new name or use the same one- Checkbox "with password" is unchecked. Close Document Reopen Document - you have to enter PW. Document will never lost PW. Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
(In reply to Thomas Krumbein from comment #26) Yes, sure. The duplicates cover all the kinds of documents: ODT, ODS, DOC, XLS, DOCX, XLSX, and their templates. And of course, this also affects ODG and ODP/PPTX. The problem is not specific to file type, it is specific to password-protected state.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd4670b976b00d643f335516fe5fd0c880d58025 tdf#133771: remove encryption data during SaveAs It will be available in 7.1.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.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/0de0b1b64a1c122254bb821ea0eb9b038875e8d4 tdf#133771: remove encryption data during SaveAs It will be available in 7.0.3. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f308520f1e3624c88e2a0e99be2eb26e2f2d0fc4 tdf#133771: sw_ooxmlexport14: Add unittest It will be available in 7.1.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/91d7c32812a5350633d2acb5e4c524bf5edc5f60 tdf#133771: sw_ooxmlexport14: Add unittest It will be available in 7.0.4. 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.
unittest added. Setting to VERIFIED @Vasily, thanks for fixing this issue!