Created attachment 117122 [details] Error during password protecting macro I prepared a complex macro made of about 50 subs with about 5300 lines of code (about 200000 characters). When I try to password protect it I receive an error indication related to the fact that the library seems to be too large to be stored in a binary format. So it is impossible to protect it without splitting it in smaller modules. This are the steps I follow to obtain the problem: (I use the italian version of Libreoffice) 1. Strumenti -> Macro -> Organizza Macro -> LibreOffice Basic... 2. Gestione 3. Librerie Then from the "Posizione" drop down menù I select my spreadsheet name (I created a library other than the standard one) then I select the library name and clic on "Password" button. Then I insert new password and I confirm it. Then click on "OK" button then clic on "Chiudi" button and then on "Chiudi" button again. Then I try to save the file with name and I obtain the following attached error. The error is present also in version 4.4.4.3
@Noel - any thoughts on this one? It's a bit hard without the actual macro to triage it :-/
(In reply to Joel Madero from comment #1) > @Noel - any thoughts on this one? It's a bit hard without the actual macro > to triage it :-/ here https://bz.apache.org/ooo/show_bug.cgi?id=64377 there are some examples. the one I could check is attachment 39533. When I try to password protect the module I receive the error I reported. Hope it can help. I obtained the same error also using an old version of Open Office 3.4.0 build 9590. In the same page there are examples that seems to be password protected but I could not open them because I do not know the password used to create them.
Test document: https://bz.apache.org/ooo/attachment.cgi?id=39533 In English: Tools - Macros - Organize dialogs Libraries Select the document name in the Location dropdown. Select Xray and set a password. Saving gives the error: Error saving the document test-ray-bigmodule: You are about to save/export a password protected basic library containing module(s) _Main which are too large to store in binary format. If you wish users that don't have access to the library password to be able to run macros in those module(s) you must split those modules into a number of smaller modules. Do you wish to continue to save/export this library? Win 7 Pro 64-bit, Version: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8 Locale: fi_FI
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Dear Mr.Crocodile, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hi all and sorry for my late answer. I follow your advise and downloaded both version 3.3.0 and latest 7.1.3.2. I made the test with the document indicated in the comment by Buovjaga 2015-07-29 15:48:42 UTC. The error is still the same (as reported by Buovjaga 2015-07-29 15:48:42 UTC) with the latest version and with the oldest one. Hope this could help again. Have a nice evening.
These are the information from Help -> About Libreoffice Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: threaded Just for information, the problem is present also using Win10
The timeline of this issue: 1. In 2006 (during OOo 2.2 release cycle), in https://bz.apache.org/ooo/show_bug.cgi?id=64377, Noel Power had implemented a new binary image format (v.0x12 - see basic/source/inc/filefmt.hxx) that is able to store more than 64K data (there are 38 commits returned by 'git log --grep i64377'). At that time, it was decided that, although the new format can fix this problem, they will *not* store it to ODF because it would be backward-incompatible. The import code was made able to read the new format, though - to be compatible with *some* future OOo version that starts writing that format. The error message (warning) was implemented, as documented in http://specs.openoffice.org/scripting_framework/BasicImageSizeIncreaseWarning.odt. All OOo/LO/AOO versions since 2006 are thus able to read binary format 0x12. 2. In 2015 (during LO 5.1 release cycle), in tdf#94617, Laurent Godard had implemented yet another incompatible change to the binary format (v.0x13) that fixed a problem in previous format that procedures could only start in the first 64K of the binary image (https://git.libreoffice.org/core/+/ddb45261590939d884ac2bcb1fd258de7b2370da). That made the new image in LO incompatible with all older LO versions, as well as with all OOo/AOO versions. 3. In 2016 (during LO 5.2 release cycle), in tdf#87530, Michael Stahl made the *new* binary image format to actually write to ODF (https://git.libreoffice.org/core/+/6a351c5cf91d0f667168d834ba2eb5c04121c7d5). Possibly this was an unintended side effect. Since then, the warning displayed by LibreOffice (starting with "Error saving..."!) is in fact *wrong*, since confirming it (pressing OK) in fact saves the encrypted module and binary image, and all LO versions since LO 5.0.3 are able to run it. The problems here: 1. Clarify the warning, to make it clear that only *old* versions of LO would be unable to use the big module. 2. Possibly change the fix to tdf#94617, so that image version 0x13 is only written when needed (i.e., when there actually is a procedure starting at offset greater than 64K), and use version 0x12 otherwise, so that when possible, the encrypted library is usable in all OOo/AOO/LO versions starting from OOo 2.2 (this is a task for a separate report). This one (about clarification of the existing message) is an easy hack related to UI; I hope Heiko could mentor it.
uui/inc/ids.hrc RID_UUI_ERRHDL "You are about to save/export a password protected basic library containing module(s) \n$(ARG1)\nwhich are too large to store in binary format. If you wish users that don't have access to the library password to be able to run macros in those module(s) you must split those modules into a number of smaller modules. Do you wish to continue to save/export this library?" The message is pretty clear- and unclear at the same time. I understand that splitting is required since the library is too large but I don't get why. And it is absolutely unclear what continue means. How about this text: "You are saving a password protected Basic library containing the module(s): \n$(ARG1)\n We cannot store this large module(s) in binary format, which is necessary for the password protection. If you want to proceed with protection please split the module into smaller pieces." and [Save without password] [Cancel] (The button label might be tricky, see uui/source/iahndl.cxx)
(In reply to Heiko Tietze from comment #9) Let me clarify. The message is wrong in that it states that we "can't" do this. We actually can, and in fact *do* store the binary, and the size is not too large. The only problem is - it would not be readable by old program version. But in fact, *any* size of the module is written by LibreOffice in such a way that is incompatible with anything older than LO v.5.2, which is a separate issue (tdf#142391). So either the warning should be removed, or it should tell that the written binary image would be incompatible with old programs (and the message depends on tdf#142391 - when it's fixed, this message should talk about OOo 2.2).
So another iteration: You are saving a password protected Basic library containing the module(s): \n$(ARG1)\n Storing those large module(s) in binary format, which is necessary for the password protection, make them unreadable in versions older than v5.2 or in Apache OpenOffice. If you want this please split the module into smaller pieces." [Save anyway] [Save without password] [Cancel] If we need to keep the Yes/No buttons: ... Press Yes to continue anyway or No if you want to split the module into smaller pieces.
(In reply to Heiko Tietze from comment #11) I generally like this. > ... in versions older than v5.2 ... I am sorry for being inattentive, my fault: I should had written "5.0.3" instead of "5.2" in comment 10. Sorry, This doesn't change much here, only the version number :-) > [Save anyway] [Save without password] [Cancel] The "Save without password" is impossible option here, since the password is applied to a specific Basic library, not to the file as a whole. Or its behavior would need to be very convoluted. I suggest to keep only proceed/abort options (using whatever wording you prefer), and if user wants, they may always abort and remove the password themselves (the message could in theory include a hint how to do that - but it's going to be lengthy).
(In reply to Mike Kaganski from comment #12) > proceed/abort options (using whatever wording you prefer) Descriptive labels on button are better since people tent to not read text, esp. when it's a long paragraph like here.
After Bug 142391 was solved, we should update the error message now.
Created attachment 188445 [details] A password-protected Basic library, with image version 0x11. Andreas, As discussed, this is a document containing an image in legacy format. I created it using OOo 1.0.3; it is a SXW, and I have checked that already there, the image version was 0x11. I wonder, which version created older versions? The password for the Library1 is 1234. It contains a single module with a single sub, that shows a message. It seems to me, that unless the library is changed, SbiImage::Save isn't called at all - the original image is saved as is. And when the library is changed, it is generated anew, already with version 0x12. Please test yourself. If what we discussed is correct, we can simply drop everything that is used for legacy image creation - we may only keep the reading code. And then have the simple message specific to version 0x13.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17154ceafe4b96b43fdc9994736e378d6a11f3e4 tdf#92620 - Adjust error message about exceeding legacy module size It will be available in 24.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.