Problem description: When the user library is password protected, there are issues with unicode? (cyrillic in my case) strings. Steps to reproduce: 1. create user library 2. enter some sample code Dim oDoc As Object Dim oSheet As Object Dim oCell As Object oDoc = ThisComponent oSheet = oDoc.Sheets(0) oCellTest = oSheet.getCellRangeByName("A1") oCellTest.String = "Ленинский проспект" 2. run the macro - works fine (displays Ленинский проспект string in the A1 cell) 3. password protect the module 4. run the macro again - does not work fine (displays ???????? ??????? string in the A1 cell) Current behavior: The cyrillic characters are replaced with question marks when the module is password protected. Expected behavior: The cyrillic characters display just fine, no matter whether the module is password protected or not. Platform (if different from the browser): Browser: Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.10
Created attachment 70101 [details] Test files (LO Calc) to demonstrate the issue. password-test-protected.ods: password protected user library demonstrating the described issue password-test-unprotected.ods: unprotected user library, no issues (included for comparison)
The problem seems to not be platform-specific, I've tested it in Windows XP 32-bit (Czech), Windows 7 64-bit (English) and OpenSUSE (Czech) and the behaviour is identical everywhere. The problem is not caused by the presence of the password protection itself; once the password is entered ("becomes known to LO"), all works fine even in protected document. But if the end-user doesn't know the password protecting the BASIC library (this is intended), he/she is stuck.
*** Bug 58426 has been marked as a duplicate of this bug. ***
Ubuntu 14.04 x64 LibreOffice 4.2.4.2 release +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Just tested this on 4.2.4.2 release and it seems to work fine. Marking as: RESOLVED WORKSFORME If you still have this problem on 4.2.4.2 release please mark the bug as UNCONFIRMED and let us know your platform. Thanks!
Thanks for the feedback, unfortunately it does not work for me. Xubuntu 14.04 x86 (Ubuntu 14.04 LTS + Xfce 4.10), Czech localization in case it matters LibreOffice 4.2.4.2 release I tried both original test file included in attachment 70101 [details] (comment 2 in this thread) and a new file created from the scratch (in 4.2.4.2) and the behaviour is identical (broken) in both cases. On Windows platform it is the same. Steps to reproduce: - download the attachment 70101 [details] above - open the file password-test-protected.ods from within it - click on the "Run Test" button - text string "This should display in cyrillic: ????????? ????????." appears in the A1 cell, i. e. question marks instead of cyrillic characters When I do the same with the file password-test-unprotected.ods, the string is displayed correctly after pressing the "Run Test" button. See attached pair of screenshots. It is important to NOT unlock the library (by entering the password) before pressing the "Run Test" button.
Created attachment 99565 [details] Illustration of behaviour (for comment 5)
Please don't change the version - it reflects the oldest confirmed version not the latest tested on. Thanks!
Created attachment 105034 [details] screenshot showing where the "password protect" is Reproduced with version 4.3.1.1, Win7. Set to NEW. Password protect = protect the "libary", not the document, see screenshot.
Created attachment 105035 [details] An ODS file with password-protected macro library
** 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.0.0.5 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
The bug is still present, tested on both Kevin Suo’s Chinese example and my Russian example, the behaviour is exactly the same as before (in earlier versions). Windows 7 Professional SP1 (x64), LibreOffice 5.0.1.2.
** 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
The bug is still present on a currently supported version. No changes in behaviour. Sample documents provided back in 2012 (comment #1 in this thread) are still usable for demonstrating the issue. Tested on Windows 7 Professional SP1 (x64), LibreOffice 5.2.1.2.
** 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.4.1 or 5.3.6 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-20170929
Still confirmed Arch Linux 64-bit Version: 6.4.0.0.alpha0+ Build ID: 37fc9f51a8de11d40632e8cda17ccf1fa4b1f503 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 6 August 2019
The problem happens at file save stage. The strings are written to the binary image (Module1.bin) in SfxScriptLibraryContainer::implStorePasswordLibrary; it calls SbModule::StoreBinaryData, which in turn calls SbiImage::Save. The strings are 1-byte-encoded: the encoding used is initially taken from current thread text encoding (on Windows, that's always system encoding); the loaded module might change the encoding (see SbiImage::Load); and *both SbiImage::Load and SbiImage::Save* filter the possible encoding to only be 1-byte encoding (using resp. GetSOLoadTextEncoding and GetSOStoreTextEncoding). It means, for instance, that UTF-8 is impossible for the encoding of strings here. If current system encoding happens to support the characters in the module, then the resulting image would contain the properly encoded characters (e.g., when I open protected document from attachment 70101 [details] on my Russian Windows, open the module entering the password, and then save the document), the image has the correct Cyrillic characters (and correct encoding number), so then the resulting file may be used without the password later. But I suppose that the test file was created on a system with non-Cyrillic thread encoding. I don't know if it's possible to change the format to accept UTF-8 as encoding. Hope that the analysis would help.
https://gerrit.libreoffice.org/c/core/+/86065
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4abb191916916c7003deedcfdcf46287faccaf01 tdf#57113: store UTF-16 stringpool data after legacy 1-byte data It will be available in 6.5.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.
As noted in comment 16, the Unicode data was not stored in the binary image of password-protected library. So the fix consists of writing new data to the image, and reading it back. Hence, the documents saved in older versions will still have broken Unicode strings in fixed versions, until libraries loaded, and re-saved. Older versions, naturally, will be unable to see new data, and will only have broken strings. To test the fix: open attachment 70101 [details] from comment 0, open the password-protected library, and re-save. Then re-open and test.
*** Bug 127763 has been marked as a duplicate of this bug. ***