Description: Starting version 2024.2.2 I can no longer unprotect a protected macro library in Calc. The spinning wheel appears and never goes back. The application hangs. Steps to Reproduce: 1.Protect a macro library using "Tools --> Macros --> Organize Macros --> Basic..." Select "Organizer...". Select the tab "Libraries" on the pop-up window Select the local file in the dropdown under "Location:". Select the library. In my case this is "LocalAddons" Click "Password..." Enter your password of choice under "New Password" and confirm. 2. Save and close the file 3. Reopen the file and try to remove the password by following the steps under 1. Actual Results: Application crashes. Expected Results: Password is removed. Reproducible: Always User Profile Reset: Yes Additional Info: This is tested with 24.2.2.2 and 24.2.3.1 on macOS Sonoma and Windows 10. A file with a macro library that has been password protected with these versions can not be unprotected. Not by these versions, nor by older versions. Going back to 7.6.6 works if you start from a file with an unprotected macro library. Help - About info: Version: 24.2.3.1 (AARCH64) / LibreOffice Community Build ID: fc604d5980a783e74808a001f1918a603d920494 CPU threads: 8; OS: macOS 14.4.1; UI render: default; VCL: osx Locale: nl-NL (en_US.UTF-8); UI: en-US Calc: threaded
I could not reproduce the issue, using: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded At step 3, I was able to click Password, enter the old password, and leave the new password fields empty. The library was then unprotected. Let's see if someone can reproduce on macOS.
Just checking: did you save, close and then reopen the file? I can re-enter the password fine, as long as I don't close and reopen the file.
(In reply to Theo from comment #2) > Just checking: did you save, close and then reopen the file? > I can re-enter the password fine, as long as I don't close and reopen the > file. Yes, I did that. Can't reproduce on Linux, with gtk3 nor gen VCL plugins. I also tested on Windows 11 with LO 24.2.2.2, couldn't reproduce either. I can't start my macOS VM at the moment, so will have to wait for another mac user to test.
Created attachment 194193 [details] test spreadsheet with macro libraries included I have copied the macro libraries to an empty spreadsheet. This file gives the same problem with me. The macro library has been protected with the password 'test'. I can not unprotect this macro library.
(In reply to Theo from comment #4) > The macro library has been protected with the password 'test'. I can not > unprotect this macro library. How exactly are you trying to achieve that? Do you mean that you: 1. input the old password in the Old Password field, 2. leave the 2 fields under New Password empty, 3. and then click OK? Please confirm whether that's the procedure that you used in order to attempt to unprotect the macro library. IDK whether this is the adequate procedure that should be used, but if this is the procedure you followed, (I think) I can replicate the crash on MS Windows using attachment 194193 [details] with LO 24.2.3.2.
What @ady describes is exactly what mean. Try those three steps and the applications hang, where it should just unprotect the library and come back.
While I can replicate the crash in LO 24.2.3.2 when starting with attachment 194193 [details], which already has a password for the macro library, I was trying to replicate the complete procedure, starting with no password, setting a password, and _then_ removing it. I tried to reproduce the steps using attachment 194193 [details] with LO 7.6.6. The Old Password ("test") is not accepted, so the rest of the details don't matter. Since this procedure failed for me (i.e. old password not accepted in LO 7.6.6), I am now wondering whether the problem could be related to the changes to encryption that were introduced for LO 24.2.
(In reply to Theo from comment #4) > Created attachment 194193 [details] > test spreadsheet with macro libraries included With the sample file, I get a hang when trying to remove the password from LocalAddOns. Repro in recent daily build and: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded In 7.6.7.2, using "test" as the password would result in "Invalid password" (are you sure you used that password?), but no freeze. I don't know why it is considered invalid, but at least the hang is a regression. Bibisected with linux-64-24.2 repo to first bad build [1921ab0d30238da3949395ee4c2450a264a69568] which points to 4995e0669da0e499743b21c60da1ca8b14a1c78c which is a cherrypick of: commit 2f512aaa6c39390a5a0eb1d1e37f070127d068a4 author Michael Stahl Tue Dec 19 19:13:00 2023 +0100 committer Michael Stahl Wed Dec 20 18:29:36 2023 +0100 tdf#105844 offapi,package,sfx2: use Argon2 for wholesome ODF encryption Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161009 Michael, can you please have a look?
(In reply to ady from comment #7) > While I can replicate the crash in LO 24.2.3.2 when starting with attachment > 194193 [details], which already has a password for the macro library, I was > trying to replicate the complete procedure, starting with no password, > setting a password, and _then_ removing it. > > I tried to reproduce the steps using attachment 194193 [details] with LO > 7.6.6. The Old Password ("test") is not accepted, so the rest of the details > don't matter. > > Since this procedure failed for me (i.e. old password not accepted in LO > 7.6.6), I am now wondering whether the problem could be related to the > changes to encryption that were introduced for LO 24.2. I was commenting at the same time, and see the same results. The files meta.xml shows the file was last saved with LO 24.2.2. Theo, do you have more details on the history the file went through? Would be good to know how we can reproduce from scratch.
In response to comment #9: The file in the attachment was just created today; an empty spreadsheet, just with the macro library imported from the actual file. The source is a rather complex spreadsheet that has a history going back to 2015. In the test file I protected the macro library with the password ‘test’ (without the quotes obviously). I’ll make a second test file with the same library but then not password protected. I can confirm that I can use the original spreadsheet in the intended way, that is with password protection, without any issues with versions 7.x
Created attachment 194202 [details] test spreadsheet with unprotected macro library I created test2.ods in the same way as test.ods: an empty spreadsheet with the macro library imported. The only difference compared to test.ods should be that in test2.ods the macro library is not password protected. For the rest the files should be identical.
(In reply to Theo from comment #11) > Created attachment 194202 [details] > test spreadsheet with unprotected macro library Thanks. If I test with this file, I only get a short hang: set password, save, close, open, remove password -> hang for a few seconds, but eventually finishes. Whereas with attachment 194193 [details], I eventually kill LO as it doesn't look it'll ever finish it. (No high CPU or memory use though.)
(In reply to Theo from comment #11) > Created attachment 194202 [details] > test spreadsheet with unprotected macro library No crash with this test2. I made 3 copies of this file. I first used LO 7.6.6. Open test2.ods (original), follow steps from comment 0. no crash. I repeated the steps using LO 24.2.3.2, also with (a copy of) the original test2.ods. No crash. Then I take the third copy of test2.ods, open it with LO 7.6.6, add a password as in comment 0, save the file, close LO 7.6.6., open the saved-file with LO 24.2.3.2, remove the password as described in comment 5, save, close, reload. No crash. There is a delay (with no clues/hints to the user) after each password (re-)set and I have to be patient, but no crash.
I just downloaded test2.ods from here (to make sure I am using the same copy as @ady). Password protect the macro library, save the file, close the file and reopen it: LO 24.2 hangs when I try to unprotect the macro library. BTW: when I try an incorrect password (on purpose) LO 24.2 also hangs. I can confirm that a file with a macro library that was password protected by LO24.2 can not be unprotected by LO 7.6. LO comes back with "incorrect password".
(In reply to Theo from comment #14) I repeated the tests, within each version and also mixing them. Other than the delay, during which I patiently wait without clicking on anything nor pressing on any key, I have no problem when I test with test2.ods, attachment 194202 [details]. I also attempted introducing an incorrect password. The delay is there too, but eventually the invalid password message shows up. I always saved, closed, and reloaded the file before proceeding with the next step. Maybe there is some user's action during the delay (of which the user has no clue about, as it would seem that Calc is just waiting) that triggers the crash. @Theo, Is it possible that clicking multiple times on the OK button while awaiting for Calc to react triggers the crash? Could you think of any user's action (as oppose to patiently awaiting Calc) that might influence the outcome? Regarding the difference between test.ods attachment 194193 [details], and test2.ods attachment 194202 [details], I guess that whatever is happening while introducing the password and saving the file in @Theo's system might be "breaking" something. I have to wonder whether the "UI render: default" setting in @Theo's system makes any difference. That, together with the OS. Someone with the same OS as @Theo's (macOS 14.4.1) should try to reproduce the behavior using test2.ods attachment 194202 [details] and report back. I cannot reproduce the crash with that file on MS Windows.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/31698044cd1fe7a7662740b97ea58f9904b3bb0e tdf#160888 package: fix opening password protected scripting library It will be available in 25.2.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.
fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/ab51f1d3a6b5c40d38339efb2c1f06cfa966fcfe tdf#160888 package: fix opening password protected scripting library It will be available in 24.8.0.0.beta2. 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.
tested with MacOSX-aarch64@tb94-TDF 2024-06-18 05:20:07 and all works well now. Thank you for the fix!
Thanks Michael, Ady and Theo! (Theo, you can change a report's status from "resolved" to "verified" when you confirm the fix works for you.)
As stated in https://bugs.documentfoundation.org/show_bug.cgi?id=160888#c19 Fix has been verified to work in daily Master: MacOSX-aarch64@tb94-TDF 2024-06-18 05:20:07
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b4857738bb7734e88a985fab6a38d0be37cb21ba tdf#160888 package: fix opening password protected scripting library It will be available in 24.2.5. 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.