Bug 114819 - Macro code corrupted with password protected macro after change in 6.0 (steps in comment 5)
Summary: Macro code corrupted with password protected macro after change in 6.0 (steps...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-01-03 11:32 UTC by Gerhard Schaber
Modified: 2018-01-08 23:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Displayed error when (12.51 KB, image/jpeg)
2018-01-03 11:32 UTC, Gerhard Schaber
Details
File saved with 5.4.4 (28.76 KB, application/vnd.sun.xml.base)
2018-01-03 12:50 UTC, Gerhard Schaber
Details
File saved with 6.0 (28.69 KB, application/vnd.sun.xml.base)
2018-01-03 12:51 UTC, Gerhard Schaber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Schaber 2018-01-03 11:32:00 UTC
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.
Comment 1 Gerhard Schaber 2018-01-03 11:38:37 UTC
I am using JRE 8.151, Windows 10, a Firebird ODB file.
Comment 2 Gerhard Schaber 2018-01-03 12:50:12 UTC
Created attachment 138848 [details]
File saved with 5.4.4
Comment 3 Gerhard Schaber 2018-01-03 12:51:00 UTC
Created attachment 138849 [details]
File saved with 6.0
Comment 4 Gerhard Schaber 2018-01-03 12:51:20 UTC
Password is "test"
Comment 5 Gerhard Schaber 2018-01-03 13:33:44 UTC
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.
Comment 6 Gerhard Schaber 2018-01-03 15:04:43 UTC
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.
Comment 7 Xisco Faulí 2018-01-04 16:07:29 UTC
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
Comment 8 Xisco Faulí 2018-01-04 16:41:18 UTC
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
Comment 9 Michael Meeks 2018-01-05 12:20:45 UTC
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 ].
Comment 10 Commit Notification 2018-01-06 15:00:51 UTC
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.
Comment 11 Commit Notification 2018-01-07 14:15:19 UTC
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.
Comment 12 Xisco Faulí 2018-01-08 10:09:18 UTC
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
Comment 13 Gerhard Schaber 2018-01-08 23:30:26 UTC
I can confirm this as well.