Bug 123877 - "Hash incompatible" in calc spreadsheet
Summary: "Hash incompatible" in calc spreadsheet
Status: VERIFIED FIXED
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: target:7.4.0 target:7.3.4
Keywords:
: 123920 147625 (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: 2022-05-31 07:12 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:
Regression By:


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 :)
Comment 14 Oliver 2022-01-28 14:49:13 UTC
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.
Comment 15 Gabor Kelemen (allotropia) 2022-03-01 11:15:21 UTC
*** Bug 147625 has been marked as a duplicate of this bug. ***
Comment 16 Commit Notification 2022-05-17 13:36:31 UTC
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.
Comment 17 László Németh 2022-05-17 13:37:10 UTC
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
Comment 18 Commit Notification 2022-05-18 14:48:49 UTC
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.
Comment 19 László Németh 2022-05-18 15:56:25 UTC
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.
Comment 20 NISZ LibreOffice Team 2022-05-31 07:12:45 UTC
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