Bug 123877 - "Hash incompatible" in calc spreadsheet
Summary: "Hash incompatible" in calc spreadsheet
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.1.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 123920 (view as bug list)
Depends on:
Blocks: Password-Protected XLSX-Sheet XLSX-Doc-Protection
  Show dependency treegraph
 
Reported: 2019-03-05 15:39 UTC by Mike Kaganski
Modified: 2021-07-13 17:32 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet giving "Re-type Password" on saving autorecovery information (15.52 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2019-03-05 15:39 UTC, Mike Kaganski
Details
Simple reproducer document (9.42 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2020-02-27 11:22 UTC, Gabor Kelemen (allotropia)
Details
Screenshot of the reproducer document (39.58 KB, image/png)
2020-02-27 11:24 UTC, Gabor Kelemen (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-03-05 15:39:37 UTC
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
Comment 1 Oliver Brinzing 2019-03-08 17:54:41 UTC
*** Bug 123920 has been marked as a duplicate of this bug. ***
Comment 2 Stephan van den Akker 2019-06-11 09:45:35 UTC
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.
Comment 3 Gabor Kelemen (allotropia) 2020-02-27 11:22:41 UTC
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.
Comment 4 Gabor Kelemen (allotropia) 2020-02-27 11:24:29 UTC
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
Comment 5 giors_00 2020-08-07 06:53:50 UTC
Also here. Very annoying. Only happends with autosave.
Comment 6 NISZ LibreOffice Team 2020-08-11 09:05:06 UTC
@Eike, I though you might be interested in this one...
Comment 7 Dominique Martinet 2021-02-17 03:56:17 UTC
(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.
Comment 8 Dan Willett 2021-04-05 18:55:23 UTC
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.
Comment 9 Mike Kaganski 2021-07-13 10:23:03 UTC
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 :)
Comment 10 Eike Rathke 2021-07-13 10:47:13 UTC
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.
Comment 11 Mike Kaganski 2021-07-13 11:30:59 UTC
(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
Comment 12 Eike Rathke 2021-07-13 16:36:06 UTC
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.
Comment 13 Mike Kaganski 2021-07-13 17:32:36 UTC
(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 :)