Description: LibreOffice Calc ODS files saved with passwords under 7.6.4 (X86_64) cannot be opened in 24.2.0.3 (X86_64). The error LibreOffice Calc presents is: The password is incorrect. The file cannot be opened. There is no possibility that the passwords being entered are incorrect. System is Win7, not connected to any LANs, WANs, or internet. Older versions of the same files experience the same critical issue in 24.2.0.3, but work correctly in 7.6.4. Steps to Reproduce: 1. Save ODS file with a password in LibreOffice Calc 7.6.4 (X86_64) in Win7. 2. Try to open the same file in LibreOffice Calc 24.2.0.3 (X86_64) on the same system. Actual Results: The error LibreOffice Calc presents is: The password is incorrect. The file cannot be opened. Expected Results: Open file without error. Reproducible: Always User Profile Reset: Yes Additional Info: Open file without error.
I have created a file with password in 7.6.4 It opens fine with: 24.2.1 24.8.0 Please attach a sample file, and paste the information in Menu/Help/About LibreOffice, there is an icon to copy.
(In reply to m_a_riosv from comment #1) > Please attach a sample file, and paste the information in Menu/Help/About > LibreOffice, there is an icon to copy. Please be aware that the file will be publicly available. You should create a very basic small ods file with a password with LO 7.6 that you cannot open with 24.2, if that is possible for you.
Please note the files were last saved with 7.6.4, but were created with previous versions of LibreOffice Calc. Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 and opening them in 24.2.0.3 may not yield the same results. Does LibreOffice use a standard encryption algorithm so that one can simply unzip the ODS files and decrypt them with another tool (providing the passwords to that tool, of course)? Is there any chance this bug could be a regression due to changes made when working on the following bug? https://bugs.documentfoundation.org/show_bug.cgi?id=105844 (In reply to ady from comment #2) > (In reply to m_a_riosv from comment #1) > > Please attach a sample file, and paste the information in Menu/Help/About > > LibreOffice, there is an icon to copy. > > Please be aware that the file will be publicly available. You should create > a very basic small ods file with a password with LO 7.6 that you cannot open > with 24.2, if that is possible for you. Thank you for your note. I found published instructions of how to install 2 different versions of LibreOffice on a single device, but they are not current: https://wiki.documentfoundation.org/Installing_in_parallel/Windows Is there a more current reference? I also found this QA post, but the instructions are vague: https://ask.libreoffice.org/t/can-i-run-two-versions-of-libre-office-on-the-same-machine/53720 Is there a better reference for that technique?
Created attachment 192335 [details] File to document the referenced bug This file documents the referenced bug. The password to the file is `criticalbug`.
(In reply to m_a_riosv from comment #1) > I have created a file with password in 7.6.4 > It opens fine with: > 24.2.1 > 24.8.0 > > Please attach a sample file, and paste the information in Menu/Help/About > LibreOffice, there is an icon to copy. Sample file attached per your request. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4 Locale: en-US (en_US); UI: en-US Calc: CL threaded Please note that the versions you tested with do not match the bug report.
Could not reproduce on Linux. With Experimental Features turned off, I saved a file with password with: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and then opened the file with: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I was prompted for a password, password worked, data was there.
(In reply to Jimmy from comment #3) > Please note the files were last saved with 7.6.4, but were created with > previous versions of LibreOffice Calc. > > Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 > and opening them in 24.2.0.3 may not yield the same results. Before I start testing with older versions, do you have an idea about which version was used to create the files?
(In reply to Buovjaga from comment #7) > (In reply to Jimmy from comment #3) > > Please note the files were last saved with 7.6.4, but were created with > > previous versions of LibreOffice Calc. > > > > Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 > > and opening them in 24.2.0.3 may not yield the same results. > > Before I start testing with older versions, do you have an idea about which > version was used to create the files? The sample file was created with 7.6.4: https://bugs.documentfoundation.org/show_bug.cgi?id=159512#c4
(In reply to Buovjaga from comment #7) > (In reply to Jimmy from comment #3) > > Please note the files were last saved with 7.6.4, but were created with > > previous versions of LibreOffice Calc. > > > > Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 > > and opening them in 24.2.0.3 may not yield the same results. > > Before I start testing with older versions, do you have an idea about which > version was used to create the files? I replied with the version used to create the test file, then realized more information may be useful to you. I'm researching to get you an approximate date when the non-test files were originally created, which will indicate the approximate LibreOffice Calc version number.
(In reply to Buovjaga from comment #7) > (In reply to Jimmy from comment #3) > > Please note the files were last saved with 7.6.4, but were created with > > previous versions of LibreOffice Calc. > > > > Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 > > and opening them in 24.2.0.3 may not yield the same results. > > Before I start testing with older versions, do you have an idea about which > version was used to create the files? Fortunately, the LibreOffice team publishes excellent release logs, and I was able to match those up with other known dates. It appears the files for which resulted in this bug being discovered were originally created with 7.1.6 and/or 7.1.7. This is an approximate, but I estimate the accuracy to be at least 85%. This sample file was 100% created with 7.6.4: https://bugs.documentfoundation.org/show_bug.cgi?id=159512#c4
(In reply to Jimmy from comment #10) > (In reply to Buovjaga from comment #7) > > (In reply to Jimmy from comment #3) > > > Please note the files were last saved with 7.6.4, but were created with > > > previous versions of LibreOffice Calc. > > > > > > Thus, simply trying to reproduce the issue by saving new ODS files in 7.6.4 > > > and opening them in 24.2.0.3 may not yield the same results. > > > > Before I start testing with older versions, do you have an idea about which > > version was used to create the files? > > Fortunately, the LibreOffice team publishes excellent release logs, and I > was able to match those up with other known dates. It appears the files for > which resulted in this bug being discovered were originally created with > 7.1.6 and/or 7.1.7. This is an approximate, but I estimate the accuracy to > be at least 85%. > > This sample file was 100% created with 7.6.4: > https://bugs.documentfoundation.org/show_bug.cgi?id=159512#c4 Ok, I created a file with a password with 7.1, saved it with 7.6 and opened it with 24.2. It accepted my password just fine.
> Ok, I created a file with a password with 7.1, saved it with 7.6 and opened > it with 24.2. It accepted my password just fine. That sounds like a reasonable approximation. It's unlikely to be identical, but likely to be fairly close. We had a "mid-air collision" as we were both posting at the same time, and this is what I was adding to our research during that collision: Two new pieces of data crossed my path, including the fact that the LibreOffice release dates I was referencing were technically "preliminary dates": https://wiki.documentfoundation.org/ReleasePlan/7.1 I also found a new piece of data that indicates one of the original files was likely created on 2021 May 10. That would suggest a slightly earlier created-by version, such as 7.1.3 or 7.1.4. What I don't know, and will never be able to know (unless it is included in the ODS metadata by LibreOffice), is if the original files were password protected, or if the password protection was added with a later version of LibreOffice Calc. Aside from this somewhat minor new details above, one must wonder what causes the different experiences. It could be the OS difference or another lower level difference. Did you get a chance to try the sample file that was attached to this bug report?
(In reply to Jimmy from comment #12) > Did you get a chance to try the sample file that was attached to this bug > report? Opens fine with the password with 24.2.0 on Win
unable to reproduce when opening file with current master build
Not reproducible: Version: 24.2.1.0.0+ (X86_64) / LibreOffice Community Build ID: cafcc50570f9edaaebe74d2152bae5df1cc2edfe CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Given that a couple people could not reproduce on other operating systems, can someone try to reproduce on the same OS as the original bug report?
(In reply to Jimmy from comment #16) > Given that a couple people could not reproduce on other operating systems, > can someone try to reproduce on the same OS as the original bug report? @Jimmy, Could you please test with a recent Win x32 variant on your Win 7 OS and post the results? Even better if you could additionally also create a new file from scratch in such version (I mean in addition to the file(s) you have been tested with until now, created on other versions of LO). A possibility could be to test with a development version from: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/ Please also use menu "Help > About" on that Win x32 version variant and click the icon in that dialogue to copy the info to your clipboard; then paste the info in your next comment report. TIA.
*** Bug 159727 has been marked as a duplicate of this bug. ***
NEW per dupe (waiting for info about Win version).
(In reply to Buovjaga from comment #19) > NEW per dupe (waiting for info about Win version). Reporter of dupe confirmed: Windows 7!
The following side note might be related to the origin of the problem. Context: * VBox VM with *no network connection*. * Guest OS (plus VBox Guest Additions): Win 7 SP1 x32 (build 7601) from 2018-08 (aka August 2018 "refresh"). * Installed on the Guest OS: Current MS Visual C++ Redistributable x86 version 14.38.33135.0. * Installed on the Guest OS: LibreOffice 24.8 alpha 32 bits Win-x86 downloaded from: dev-builds.libreoffice.org/daily/master/Win-x86@39/2024-02-17_00.08.15 NAME: master~2024-02-17_00.08.15_LibreOfficeDev_24.8.0.0.alpha0_Win_x86.msi SIZE: 217'223'168 bytes MD5: 41344864ef938f290037ad93fd8fdb78 Note: I attempted to install KB3063858 (x86) mentioned in the System Requirements for Windows 7 SP1, but the procedure resulted in a message that says "The update is not applicable to your computer". I don't know whether this is because the Win 7 SP1 "refresh" is dated later than KB3063858 (which, AFAIU, it is), or because some other reason. RESULT: After installation, when trying to run LibreOffice, the following message is shown on screen (and LO does _not_ start): soffice.bin - Entry Point Not Found The procedure entry point BCCryptKeyDerivation could not be located in the dynamic link library bcrypt.dll. This suggests that LO (at least 24.8 alpha, and possibly other versions too) requires a specific version (or versions) of bcrypt.dll that is (are) not necessarily installed on every Windows 7 (SP1) system. Maybe an updated (after 2018-08) bcrypt.dll for Windows 7 might not have these problems; that is yet to be tested (by knowledgeable devs). There might be some MS's patch (whether after 2018-08, or rolling back to some older point) that might solve the bcrypt.dll problem. Or, there might be some legal way for users to obtain and install a valid bcrypt.dll file for Windows 7 SP1 that would not generate this (compatibility?) problem(s) for LO.
(In reply to ady from comment #21) > soffice.bin - Entry Point Not Found > The procedure entry point BCCryptKeyDerivation could not be located in the > dynamic link library bcrypt.dll. Sorry for the typo (one extra "C"); that should had been: soffice.bin - Entry Point Not Found The procedure entry point BCryptKeyDerivation could not be located in the dynamic link library bcrypt.dll. Probably the System Requirements for usage of LibreOffice might need some tweaking / refinement, in order for LO to run on Windows 7 (e.g. some additional or alternative KB patch). Or, LO needs some internal code review in order for it to run on Windows 7 with the current System Requirements. Should additional devs be CC'ed?
*** Bug 159770 has been marked as a duplicate of this bug. ***
Setting to "high - major" as this makes it impossible to open existing files in a new installation. Windows is not supported by Microsoft anymore (even the paid-for extended support expired), but we declare we still support it: https://www.libreoffice.org/get-help/system-requirements/
(In reply to ady from comment #21) BCryptKeyDerivation [1] only appeared in Windows 8 (see "Requirements" there). Interestingly, LibreOffice code does not refer to this function itself. But likely, some library depends on it; possibly we don't pass the Windows version properly to it, so it doesn't correctly choose the supported code block. Or maybe an upgrade of that library started using a version that doesn't support our baseline. FTR, grepping for "BCryptKeyDerivation" in workdir gives four matches under UnpackedTarball/xmlsec. Gut searching on their github repo [2], I don't see occurrences of BCryptKeyDerivation. But the specific "soffice.bin - Entry Point Not Found" is different - the reporters can run the program, but can't open the files ... [1] https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptkeyderivation [2] https://github.com/lsh123/xmlsec
*** This bug has been marked as a duplicate of bug 159519 ***