Bug 89320 - LibO opens a password-protected .docx, displaying garbled text, when user presses cancel instead of entering a password
Summary: LibO opens a password-protected .docx, displaying garbled text, when user pre...
Status: RESOLVED DUPLICATE of bug 80999
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 93280 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-11 21:35 UTC by Jennifer
Modified: 2015-12-15 11:03 UTC (History)
6 users (show)

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


Attachments
A password protected .docx file for debugging and testing. (19.50 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2015-02-17 15:46 UTC, Jennifer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jennifer 2015-02-11 21:35:46 UTC
In the LibreOffice application, when I open a pre-existing docx file that is password protected, and I click cancel when prompted for the password, LibreOffice still opens the document, but all the content is garbled.

We are using unoconv with headless LibreOffice for automating converting documents to html. Up until now, we have used LibreOffice v 4.1 together with unoconv 0.6. With this version, attempting to convert the document fails with the message:

The document [document name] could not be opened.


But we have just upgraded to LibreOffice 4.3, and now LibreOffice "successfully" converts the document, though the output is unreadable.

This creates a problem with our automation, because this result is reported back to our users, rather than giving them a more useful error message that the document couldn't be converted.

And I think for your LibreOffice application users, the user experience is much worse when they are presented with the garbled document.
Comment 1 Jan 2015-02-13 12:43:44 UTC
setting 4.3 as first affected version and marking as regression.
Comment 2 tommy27 2015-02-14 07:51:26 UTC
please upload a dummy test file so we can try to reproduce.
is the bug specific to .docx format or happens with .doc and .odt as well?

I set status to NEEDINFO
revert it to UNCONFIRMED once you upload that file
Comment 3 Jennifer 2015-02-17 15:46:25 UTC
Created attachment 113466 [details]
A password protected .docx file for debugging and testing.

Attached a password protected docx file.
(the password is 'Secret')

To make it password protected, we did the following (this was on Office for Mac):

Word menu -> Preferences -> Security tab
In there, Security options for [name of document]:
Password to open: (filled in password)
Clicked on "Protect document"

I have not tried with a regular doc file. Also, a password protected .odt file did not have the same behaviour. It worked as before.
Comment 4 Matthew Francis 2015-02-21 12:17:03 UTC
The below appears to be the commit at which we started to write a (junk) html file for a password protected .doc instead of nothing when converting with "soffice --convert-to"

Adding Cc: to mstahl@redhat.com; Could you possibly take a look at this? Thanks


commit e62339f856efa0b8ef03df3bf8b93e098c4ac0d3
Author: Michael Stahl <mstahl@redhat.com>
Date:   Mon Feb 10 16:45:27 2014 +0100

    fdo#73363: sd: fix mis-detection of Visio files as PPT
    
    SdFilterDetect::detect() erroneously detects all binary MSO files, and
    because the Visio types would be checked after PPT, Visio is pre-empted.
    
    Change-Id: I6ec3647a508dc8d79b47bfff6de35ccae39416ee
Comment 5 Maxim Monastirsky 2015-08-08 18:27:37 UTC
*** Bug 93280 has been marked as a duplicate of this bug. ***
Comment 6 Maxim Monastirsky 2015-08-08 18:58:58 UTC
(In reply to Matthew Francis from comment #4)
> The below appears to be the commit at which we started to write a (junk)
There is, of course, nothing wrong in this commit. What we should do here is to honor the MediaDescriptor::PROP_ABORTED that written by the oox detector, and stop the detection loop (and then also make sure that GUI users won't see the filter selection dialog).
Comment 7 Maxim Monastirsky 2015-08-08 21:50:24 UTC
Actually there is much earlier report.

*** This bug has been marked as a duplicate of bug 80999 ***
Comment 8 Robinson Tryon (qubit) 2015-12-15 11:03:25 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]