Bug 129096 - docx: recovered document losing password protection
Summary: docx: recovered document losing password protection
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:7.0.0 target:6.4.3 target:6.3.6
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-29 10:28 UTC by Vasily Melenchuk (CIB)
Modified: 2020-03-19 09:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vasily Melenchuk (CIB) 2019-11-29 10:28:00 UTC
Description:
If password protected DOCX document was recovered after LO crash, than it is saved after recovery without password.

Steps to Reproduce:
1. Create a password protected document in DOCX format
2. Open it in Writer
3. Crash LO (I've just killing soffice.bin with task manger)
4. Open LO once again. A document recovery dialog will appear
5. Recover & open document
6. Save it again.

Actual Results:
Saved on p.6 document is no longer password protected

Expected Results:
Password protection still applied to document.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Commit Notification 2020-02-08 17:35:44 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/15664830235fd3d34dc633affa87824e5c10cb79

tdf#129096 Don't autosave encrypted documents

It will be available in 7.0.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 2 Mike Kaganski 2020-02-08 18:55:45 UTC

*** This bug has been marked as a duplicate of bug 93389 ***
Comment 3 Commit Notification 2020-02-10 10:09:59 UTC
Thorsten Behrens committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f363ca0c0b949b60b8bb2dd43025082e4609c3f0

Revert "tdf#129096 Don't autosave encrypted documents"

It will be available in 7.0.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 4 Mike Kaganski 2020-02-11 13:58:49 UTC
Oh fun! try this:

> soffice --infilter="MS Word 2007 XML" path/to/docwithpassword.docx

and see how the same password loss happens, because when filter is given explicitly, filter detection doesn't perform decryption, and the encryption data is only created again in WriterFilter::filter, where it can't reach media descriptor.
Comment 5 Mike Kaganski 2020-02-12 06:16:55 UTC
(In reply to Mike Kaganski from comment #4)

So in general, *keeping* entered password in LibreOffice is rather *accidental* consequence of type detection stage, and both steps from comment 1 and comment 4 are results of the fact that XFilter::filter can't return or change media descriptor of the data. Possibly passing some interface (which could take a changed encryption data from filter) among the media descriptor values would be a solution? Then that object could be used in the caller to update the descriptor. Or introduce a derivative interface of XFilter with filter2() taking non-const reference to the sequence?
Comment 6 Mike Kaganski 2020-02-12 06:45:38 UTC
Note that some start center / recent list enhancements like tdf#65017, tdf#56696, that imply reusing filter information, might get affected by this if using the last-used filter (and thus skipping filter detection) is implemented.
Comment 7 Commit Notification 2020-03-02 00:32:38 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8461127750e1fe92a615409505256132e54fb8e8

tdf#129096: Document Recovery: Use TypeDetection on load

It will be available in 7.0.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 8 Commit Notification 2020-03-06 21:21:35 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/2478e861e221b2080309614ca7b29ca6c06af92f

tdf#129096: Document Recovery: Use TypeDetection on load

It will be available in 6.4.3.

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 9 Commit Notification 2020-03-19 09:08:28 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/b05c87f00433987b10542866696f0b4aaad015cc

tdf#129096: Document Recovery: Use TypeDetection on load

It will be available in 6.3.6.

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.