Download it now!
Bug 115933 - XLSX <fileSharing> password protected with algorithmName, hashValue, saltValue and spinCount
Summary: XLSX <fileSharing> password protected with algorithmName, hashValue, saltValu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0
Keywords:
Depends on:
Blocks: XLSX Password-Protected
  Show dependency treegraph
 
Reported: 2018-02-22 10:58 UTC by Bene
Modified: 2019-03-02 19:31 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Excel File in question (131.24 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-02-22 10:58 UTC, Bene
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bene 2018-02-22 10:58:00 UTC
Created attachment 140053 [details]
Excel File in question

Hi There,

I currently have a password protected Excel file with the XLSX extension, this file allows read only mode and Read and Write if the password is provided. The issue is if this file is opened using Librecalc no password is required , and the user is able to edit this same file.

Is there any solution to overcome this problem ?
Comment 1 Xisco Faulí 2018-02-22 11:41:16 UTC
Hello Bene,

This is happening because it's a blank password. Could you please try to set a minimal password and re-test?

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 2 Bene 2018-02-22 12:56:57 UTC
Hi Fauli

The file does not have a blank password, if you execute the XLSX doc in Excel you will be prompted for a password, and in Librecalc the password is bypassed.  don`t understand why the blank password statement 

Did you had the chance to have a look at the file ?
Comment 3 Xisco Faulí 2018-02-22 13:06:52 UTC
(In reply to Bene from comment #2)
> Hi Fauli
> 
> The file does not have a blank password, if you execute the XLSX doc in
> Excel you will be prompted for a password, and in Librecalc the password is
> bypassed.  don`t understand why the blank password statement 
> 
> Did you had the chance to have a look at the file ?

Yes, in MSO 2010, when the file is open the password dialog is prompted, pressing Enter displays the file, meaning the password is blanked.

The bug here is that LibreOffice should at least display the password dialog
Comment 4 Mike Kaganski 2018-02-22 13:16:25 UTC
(In reply to Xisco Faulí from comment #3)
> Yes, in MSO 2010, when the file is open the password dialog is prompted,
> pressing Enter displays the file, meaning the password is blanked.
> 

Hmm... AFAICS, the password prompt dialog in MSO (2016) has the OK button disabled, and Read Only set to default, until something is entered into the box. Enter just executes the default action (read-only).
Comment 5 Xisco Faulí 2018-02-22 13:44:07 UTC
(In reply to Mike Kaganski from comment #4)
> (In reply to Xisco Faulí from comment #3)
> > Yes, in MSO 2010, when the file is open the password dialog is prompted,
> > pressing Enter displays the file, meaning the password is blanked.
> > 
> 
> Hmm... AFAICS, the password prompt dialog in MSO (2016) has the OK button
> disabled, and Read Only set to default, until something is entered into the
> box. Enter just executes the default action (read-only).

Ouch, you're right! My bad!!

Closing as RESOLVED DUPLICATED of bug 104250

*** This bug has been marked as a duplicate of bug 104250 ***
Comment 6 Bene 2018-02-22 14:41:15 UTC
There is no clear answer to this , how do we stand ? In my opinion this is a Bug with Libreoffice there is no blank password on this file
Comment 7 Xisco Faulí 2018-02-22 14:48:07 UTC
(In reply to Bene from comment #6)
> There is no clear answer to this , how do we stand ? In my opinion this is a
> Bug with Libreoffice there is no blank password on this file

Yes it's a bug.
I was wrong when I said the password was blanked.
This bug has already been reported in bug 104250

*** This bug has been marked as a duplicate of bug 104250 ***
Comment 8 Bene 2018-02-22 16:09:09 UTC
Thanks

Is there any workaround , or plan to fix this bug. The other post dates back to 2016... where this issue was reported and identified as a Bug. Libre developers are no interested in sorting this issue ?
Comment 9 Xisco Faulí 2018-02-22 16:12:01 UTC
(In reply to Bene from comment #8)
> Thanks
> 
> Is there any workaround , or plan to fix this bug. The other post dates back
> to 2016... where this issue was reported and identified as a Bug. Libre
> developers are no interested in sorting this issue ?

Hello Bene,
it seems today is your lucky day. Eike ( our Calc expert ) is investigating it -> https://bugs.documentfoundation.org/show_bug.cgi?id=104250#c13
Comment 10 Eike Rathke 2018-02-22 22:03:30 UTC
This is not a duplicate, though similar or related. Bug 104250 is about the <sheetProtection> element, whereas this is about the <fileSharing> element.

This will need to support the <fileSharing> element with algorithmName, hashValue, saltValue and spinCount attributes and feed those with the password to be entered to the proper hashing/digest implementation.

Currently only the reservationPassword hash and readOnlyRecommended attributes are supported, which are not present here. If reservationPassword hash or readOnlyRecommended=true were present, the document would always be opened read-only. A password dialogue unprotected write open is not implemented.
Comment 11 Commit Notification 2018-02-23 10:18:07 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fe1b2fb823470e2f5eae574f9c9f877eecc932d

Read algorithmName, hashValue, saltValue, spinCount, tdf#115933 prep

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2018-02-23 10:18:13 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d5a9e9f26daf95f33afb0d28ffd088cdd41ae8c

tdf#115933 set document read-only on presence of hashValue attribute

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Eike Rathke 2018-02-23 10:34:25 UTC
With those commits an xlsx document opens read-only on presence of a <fileSharing> hashValue attribute with content. Currently there's no way to enter edit mode for such document other than saving to a different file.

Unassigning myself now to free this up for someone to take over for the "dialogue to edit" part.

If the unconditional read-only is sufficient we can backport the commits to 6-0 if wanted and/or set the bug resolved fixed.