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 :)