When I try to open password-secured xlsx file, eg: http://user.services.openoffice.org/en/forum/viewtopic.php?f=9&t=34894&start=0#p160344 I got the same errors like there. The same issue on Windows with LibO 3.3.2RC2, but there is no dialog box, either "Filter Selection" or password prompt.
Created attachment 51001 [details] password: OOTest
I'm unable to open attached file in all versions of Libo (win & linux also). It seems to be an issue with the encryption algorithm or just reading it from file. File *EncryptionInfo* (marked by "_unread" on end) from attached xlsx file is different than one from every document secured by one of following ways (in Excel 07 SP2): 1. MS Button -> Prepare -> Encrypt Document 2. Save as -> Tools -> General options -> Password to open --> Save I don't know what is different in creating the attached xlsx from mine tests. Probably the same issue was with docx files.
Created attachment 51005 [details] _unread one from the xlsx file from the attached xlsx file
Created attachment 51006 [details] EncryptionInfo which works with Libo
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Relevant links: - LIbreOffice Users mailing list discussion: http://www.mail-archive.com/users@global.libreoffice.org/msg10771.html - AskBot question: http://ask.libreoffice.org/question/933/will-version-35-support-encrypted-docx-or-xlsx?answer=950
confirming, reassigning
Created attachment 59894 [details] Unencrypted file that won't open I am experiencing this issue on certain files that do not have a password and appear to be unencrypted (how can I check?). For example, this happens with any file generated from AutoQuotes. If I unzip the .xlsx file and then zip the contents back up into a new .xlsx file, LibreOffice can open it fine. Alternatively, opening in Excel and doing a "save as" produces a file that works fine in Libre. I have attached a file that exemplifies the above scenario. My apologies if this should be a separate bug report.
Can confirm on version LibreOffice 3.5.5.3, build 350m1(Build:3) tested on xlsx document (can't attach) version of the office files were created on: 14.0300 (says file info) files without password from the same batch opens just fine.
This seems to be because the files inside xlsx are stored with '\' as separator!
Seeing this same problem with both 3.5.7 and 3.6.4 1) The files were encrypted (password) by MS Office 2010 SP1 x64. 2) The result: a) with 3.6.4 there is no password prompt and the file "opens" displaying garbled ascii characters. b) with 3.5.7 the Filter Selection window opens. It appears LO has no idea how to open the MSO 2010 file format. I can successfully open files created and encrypted by older versions of MS Office (2007 & 2003). This bug seems specific to the encryption scheme of Office 2010
Excel 2010 uses XML stream to store the encryption information whereas Excel 2007 did using the BIFF structure. Our code can only handle the BIFF version of encryption info which is why Calc fails to open Excel 2010 generated encrypted xlsx at the moment.
There are 3 variants of EncryptionInfo stream: Standard, Extensible, and Agile. Excel 2007 seems to default to the "Standard" variant, where as 2010 does "Agile".
Code pointer for the next investigation: the relevant code is in lclReadEncryptionInfo() in oox/source/core/filterdetect.cxx.
I'm turning this into an enhancement request. This is not a bug; it's rather a missing functionality. Excel 2010 uses different encryption method than that of Excel 2007, and we'll need to write a new handler code for this.
@Kohei What do you think, is this here a particular CALC problem or do we have a general MSO ....x FILEOPEN problem together with "Bug 47808 - FILEOPEN particular (encrypted?) .DOCX via Filter Selection Dialog fails with "General Error."" and similar? We have quite a lot of fileopen necrypted MSO ....x bugs, I would like to get some order into this.
This is a general issue that affects docx files as well. I recently updated myself to Libreoffice 4 and it will now open the file but in its encrypted format so the document appears to just contain garbage.
This perfectly the same faulty behavior as described in fdo#51194. Thus setting to dupe. *** This bug has been marked as a duplicate of bug 51194 ***
Mark the newer bug a duplicate of the older one please.
*** Bug 51194 has been marked as a duplicate of this bug. ***
*** Bug 63614 has been marked as a duplicate of this bug. ***
*** Bug 66941 has been marked as a duplicate of this bug. ***
*** Bug 48687 has been marked as a duplicate of this bug. ***
*** Bug 60343 has been marked as a duplicate of this bug. ***
Created attachment 84536 [details] sample word/excel/powerpoint files, encrpted and unencrypted Here are 3 very trivial documents generated in MS Windows Office 2010. For each of Excel/Word/Powerpoint, I have created a simple document, and provide it both normally and saved with the password "test" (no quotes). LO (4.1.0.4) can open all the normal versions just fine. The encrypted ones all fail with a very unhelpful dialog-box: "Version Incompatibility. Incorrect file version" Even if this bug isn't fixed properly, please at least change the text to something like: "This file might be encrypted with a password. If so, LO can't read it, so please ask the sender for an unprotected copy". That would save endless amounts of user frustration.
I have a build locally that supports opening encrypted 2010 and 2013 Office documents. After clean-up I will commit the changes to the master build so everybody can test.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4323c66840e4c7dcacda0e33d33d7e67fdb08f09 fdo#35422 Support to open encrypted Office 2010 and 2013 formats 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.
I built an LO version from commit e362f9fcd7f50d750e8549d7b93a0a9a66cbabe1 (simply the newest when I started) on Linux, and I'm able to open all the files in the attachment "sample word/excel/powerpoint files".
Yes, LO should now decrypt 2010 and 2013 documents with LO daily build.. however there is a issue with some 2013 Word documents that can't be opened even though they were correctly decrypted and I have not yet been able to figure it out why. It may be something in LO still is not supported or some other issue.
(In reply to comment #29) > Yes, LO should now decrypt 2010 and 2013 documents with LO daily build.. > however there is a issue with some 2013 Word documents that can't be opened > even though they were correctly decrypted and I have not yet been able to > figure it out why. It may be something in LO still is not supported or some > other issue. Tomaz - Can you attach the files that are not encrypted correctly ? Do you have any directions as to where the problem is ?
Hi, I could not open any encrypted docx (and only docx) that was created with Office 2013, but it decrypted the file correctly (I catched the decrypted file and opened it successfully). I tried this again yesterday but now it worked for whatever reason - I was playing with some compatibility registry hacks for Office 2013 so maybe this is the reason. I will investigate this further.. Regards, Tomaž
I can't find the problematic encrypted 2013 docx document and I could not reproduce the problem with a new documents so I will set this as resolved. Regards, Tomaž
The test case is in https://bugs.freedesktop.org/show_bug.cgi?id=51194
(In reply to comment #33) > The test case is in https://bugs.freedesktop.org/show_bug.cgi?id=51194 This test case works fine for me in LO daily build.
*** Bug 71420 has been marked as a duplicate of this bug. ***
*** Bug 71490 has been marked as a duplicate of this bug. ***