Created attachment 138842 [details] Displayed error when I have a password protected macro library with 7 modules. Everythign works fine with 5.4.4.2. When I change any code in the library with 6.0 or 6.1 and save the changes, 3 of the modules get corrupted. They cannot be loaded and edited anymore later. When I enter the password, for each of the three an error dialog is displayed. Funnily, they seem to be able to be run, so the binary representation still seems to be okay. I am still trying to create a simple test file. I cannot provide my actual library. The 3 modules all have over 55k characters, but none of them have more than 65k characters. When I try this with a simple test module with that many characters, it won't happen.
I am using JRE 8.151, Windows 10, a Firebird ODB file.
Created attachment 138848 [details] File saved with 5.4.4
Created attachment 138849 [details] File saved with 6.0
Password is "test"
1. Load the 5.4.4 file in 6.0 2. Open the macros in Library1 for editing 3. Enter the password Everything is fine 4. Then make a dummy change in the macro 5. Save the macro 6. Save the ODB file 7. Repeat steps 1-3 You get an error loading the Basic module. The Basic module cannot be repaired anymore, neither in 5.4.4. The module is empty. If you change and save it, next time LO will either report that the password is incorrect, or it will simply crash. You need to delete the module in 6.0 completely, and create a new one, and add your code again (in case you made a backup outside of the ODB file). The original code is lost, though.
I am not sure, if this is somehow related with bug 106845. The difference is that the current issue is 100% reproducible, and LO reports an error when I enter the pasword to open the macro library.
Confirmed in Version: 6.1.0.0.alpha0+ Build ID: 2bf1cc7372088ec31ac5f0fb60de57feda59d3b7 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Regression introduced by: author Michael Meeks <michael.meeks@collabora.com> 2017-07-05 17:30:27 +0100 committer Michael Meeks <michael.meeks@collabora.com> 2017-07-06 11:12:19 +0200 commit 4a8f8c09edb06e4ff812d676bc7726a8b4f6ebe8 (patch) tree 9665049f1f19ffcfb569ad9e7ffd1467037ba061 parent 5eeed755a2eadbadd7a2e0c06216258af028a96e (diff) tdf#108821 - fixed bad alloc on opening large file Workaround for streams with size > SAL_MAX_INT32. More complicated ways using available() and navigating cross-thread are possible, but probably harder to maintain. Bisected with: bibisect-linux64-6.0 Adding Cc: to Michael Meeks
Thanks for the report - looks quite simple; https://gerrit.libreoffice.org/47467 fixes this; I guess it'd be good to have a unit test - but a bit busy ... any takers ? [ we would want a very small minimal test file with an encrypted stream in it ].
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc885c071b71e6f6f76bedaecf7f0b1a81dd1d57 tdf#114819 - include the synthetic encrpytion header into the size. It will be available in 6.1.0. 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.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0435aa08f4f6504dee6065ea6e4a55fbb07b8f77&h=libreoffice-6-0 tdf#114819 - include the synthetic encrpytion header into the size. It will be available in 6.0.0.2. 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.
Verified in Version: 6.1.0.0.alpha0+ Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
I can confirm this as well.