Created attachment 149748 [details] Spreadsheet giving "Re-type Password" on saving autorecovery information See https://ask.libreoffice.org/en/question/185466. Open attachment; make a minimal edit and let Save AutoRecovery information timeout pass; on auto-saving, a dialog "Re-type Password" appears with "The document you are about to export has one or more protected items with password that cannot be exported. Please re-type your password to be able to export your document. Document protection Not protected. Sheet protection Line 5 Hash incompatible" text. Tested with Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 12; OS: Windows 10.0; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
*** Bug 123920 has been marked as a duplicate of this bug. ***
I can confirm this problem on openSUSE Tumbleweed 20190607 in version: Version: 6.2.3.2 Build ID: 20(Build:2) CPU threads: 8; OS: Linux 5.1; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded While reading through a XLSX document provided by the Dutch Government.
Created attachment 158225 [details] Simple reproducer document This also happens when saving Excel 2016 made XLSX files with sheet protection to ODS format. This started to happen since 6.1, 6.0 did not read the password yet.
Created attachment 158226 [details] Screenshot of the reproducer document Version: 7.0.0.0.alpha0+ (x64) Build ID: 41177730421f9be9ad955766a5a19667d8003b11 CPU threads: 8; OS: Windows 10.0 Build 17134; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL
Also here. Very annoying. Only happends with autosave.
@Eike, I though you might be interested in this one...
(In reply to giors_00 from comment #5) > Also here. Very annoying. Only happends with autosave. As a workaround rather than disabling autosave you can change the default save format to xlsx (or whatever it is the format of the document causing problem is); that avoids the need of going through export and thus does not seem to trigger the annoying prompt. I think the easiest way of solving this would be to always do autosave in the original document format instead of using the default format, but it's a difficult problem as if there are things that can't be represented in the original format it will lead to a suboptimal autosave copy... If it's possible to just disable the prompt on export for non-interactive save that'd probably work too.
This should be a high priority bug as if the user does not know the password, there is no way to get past the dialog, if you hit cancel, the dialog just comes back, and the only way to get past it is to kill LibreOffice.
Since using a non-native file format for a backup would be a no-go, since we would loose any information that format or import/export filters don't support, I suppose that the only fix could be to allow different hash implementations in ODF, so that it could be possible to store the original hash without asking. No idea if that's possible without an ODF change... By the way, in this current form, this feature - to ask for re-typing the password - makes the password even less useful, because when user wants to remove the password without knowing it, they simply may save to another format, and have it unprotected (with the help of the dialog when it's OOXML->ODS conversion direction, or even silently, when it's the opposite direction). Of course, the password is not a real protection - but then we either ignore it at all, or do not provide built-in password removal :)
As this is *only* necessary for autosave, I think extending ODF is not necessary if we store the known hashes along in the temporary document (maybe in a separate file in the bundle) and can read them back in. However, there might be situations where that is not wanted, like in the case of the old and weak .xls "garbles". For which adding such to ODF wouldn't be wanted either.. More sensible than sheet protection is document *encryption*, saving that without password and deriving the key is just not possible. Disabling autosave for one file if the password dialog was cancelled (with a warning) would be the remedy for those and unknowns.
(In reply to Eike Rathke from comment #10) The relevant ODF markup is table:protection-key (19.701) and table:protection-key-digest-algorithm (19.702) [1]. The latter clarifies that the values are implementation-defined; so we could use something like "OOXML-SHA512" as table:protection-key-digest-algorithm value, with all three "hashValue", "saltValue" and "spinCount" stored in table:protection-key, without any ODF extension, and without storing it elsewhere. I believe it would be correct to store in auto-recovery; while it could be questionable whether it's OK to use in Save As (my take would be "yes, when user is unable to provide the correct password, instead of allowing to drop password"). [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-table_protection-key
Hum.. yes, but that also states "The table:protection-key-digest-algorithm attribute is usable with the following elements: <office:spreadsheet> 3.7 and <table:table> 9.1.2." Is that sufficient to store Excel's protection cases? Regarding general use, I'd refrain from letting such implementation defined OOXML-... values escape into the wild.
(In reply to Eike Rathke from comment #12) > Hum.. yes, but that also states > "The table:protection-key-digest-algorithm attribute is usable with the > following elements: <office:spreadsheet> 3.7 and <table:table> 9.1.2." > Is that sufficient to store Excel's protection cases? I don't know... can we know which protection cases are handled by the dialog in question? :) > Regarding general use, I'd refrain from letting such implementation defined > OOXML-... values escape into the wild. I'm fine with this, and additionally please disregard my words about my preference about unrelated use case - this issue is only about autosave, so let me stop posting off-topic :)
This seems still to be a problem in 7.1.7.2 64bits. Sometimes this goes away when one clicks on "Ressaisir" (sorry I have the French version, in English this could be "rewrite") and then checks "delete" and OK. One needs to do this for all protected cell in the list, sometimes there are many. However not in all cases OK becomes active when checking delete.
*** Bug 147625 has been marked as a duplicate of this bug. ***
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6af4c1d097dfba897e305a1e57d1e920f36ce264 tdf#123877 sc XLSX: don't freeze during saving recovery It will be available in 7.4.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.
Commit description: tdf#123877 sc XLSX: don't freeze during saving recovery file by asking password re-typing unstoppably. Instead of this, skip recovery file saving, if the document contains password hashes which haven't been supported by the "calc8" filter of the recovery file (which triggered the "Re-type password" dialog). Solved problems: – Asking for passwords during a non-interactive background process. – A single Cancel didn't close the "Re-type password" dialog window, only pressing three times at least (according to the value of RETRY_STORE_ON_MIGHT_FULL_DISC_USEFULL), but waiting for the password for a while could result a frozen "Re-type password" dialog, where only retyping or removing the password(s) were the escape routes. – Re-typing the password required the password (but modifying the original document doesn't require this). – Removing the password resulted in loss of the protection after saving the original XLSX document. Add a UI test to keep the "Re-type password" dialog during Save As. Note: because of the regression reported in tdf#145757, it needs to wait 10 min for saving the recovery file, yet, despite the changed time in Tools->Options->Load/Save->General. Change-Id: Icc6ee4d67048cdf15ab75ef8e2ee8f1709cdd4c2
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/17c8917e6818f160b7965466851fabb351e3459a tdf#123877 sc XLSX: don't freeze during saving recovery It will be available in 7.3.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.
I suggest to file a new issue for support recovery files for the opened OOXML documents with unsupported hashes. I suggest to add a RedlineProtectionKey-like config setting (e.g. RecoverySheetProtectionKey) to store the unsupported hash only in the recovery ODS. Or as a general solution, we need a RecoveryGrabBag config setting for the recovery files, containing a JSON data sequence with the content of the GrabBags... Because now recovering is a quite lossy operation for the opened OOXML files, if I am right.
Verified in: Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 212cb61fb6adc05395b9f9afe0dacbd6594ae06b CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24c52c6f8674a716f3f5102095421c97d03b19d8 related tdf#68565 tdf#123877 autosave: identify by args, not path It will be available in 24.2.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 156799 has been marked as a duplicate of this bug. ***