Apache OpenOffice (AOO) Bugzilla – Issue 125431
"The Password is incorrect. The file cannot be opened."
Last modified: 2022-10-28 12:54:20 UTC
Created attachment 83829 [details] Info Box upon password entry Get this message box on all password protected files and cannot create new password protected files. This applies to word processing as well as Calc files.
Cannot access many files because my password no longer works, need these files please respond. I have been using this system for 8 years and suddenly I can't get into the files, there must be a fix for this ?
Does this happen with files created with previous versions? Can you attach a dummy document saved with a dummy password?
The user sent in a private mail a document with its password, the file cannot be opened with the password. I tried to reporduce on my own, but the bug isn't reproducible: - create a Writer document with 4.0.1, save it with password "test" - create another one with 4.1.0, save it with password "test" Both files can be opened in both versions.
Created attachment 83833 [details] Document with password "test" @Robert: can you open that file? The password is test
Comment on attachment 83833 [details] Document with password "test" No. Cannot open this file with password test.
http://archive.apache.org/dist/openoffice/4.0.1/binaries/en-US/Apache_OpenOffice-SDK_4.0.1_MacOS_x86_install_en-US.dmg.asc Password: Saignon This is a sample file that will not open.
(In reply to Ariel Constenla-Haile from comment #3) > The user sent in a private mail a document with its password, the file > cannot be opened with the password. Dummy me; tested again after a message from Robert telling that Rory could open the file, and the document *CAN* indeed be opened (tested on Linux and MacOSX, with 4.0.1 and 4.1.0).
Created attachment 83834 [details] Message Box received
Downloaded 4.0.1 and file password does not open. Created new file without password and no problems then tried to password protect and received box stating "Error saving document..., General Error, General input/output error"
Can you run OpenOffice from within a terminal? It may output some error message (may be a library that can't be loaded, etc.) The terminal is Terminal.app; in the terminal you have to write the command to execute OpenOffice and press Enter. The command is something like /Applications/OpenOffice.app/Contents/MacOS/soffice (if OpenOffice is in the default location). Use the TAB key to autocomplete the path to soffice.
There is bug 121086 which describes a similar problem with 3.4, the bug is open, and could not be reproduced by any developer.
I confirm that I was able to open using OO 4.1.1 RC2; OO 4,1,0 opens it on Windows XP (32 bit) and on Xubuntu 14.04 (64 bit), so it may be a Mac specific problem. RoryOF
In the Mac code does the passwording mechanism make any call for encryption to a Mac system library, which may have been updated or not updated on the problem computer? RoryOF
Other sample file from same user, password "Saignon" (do not confuse with similar named city!,) on a thread at at https://forum.openoffice.org/en/forum/viewtopic.php?f=6&t=71593
(In reply to Ariel Constenla-Haile from comment #10) > Can you run OpenOffice from within a terminal? It may output some error > message (may be a library that can't be loaded, etc.) > > The terminal is Terminal.app; in the terminal you have to write the command > to execute OpenOffice and press Enter. The command is something like > > /Applications/OpenOffice.app/Contents/MacOS/soffice > > (if OpenOffice is in the default location). Use the TAB key to autocomplete > the > path to soffice. Thanks I tried to run OpenOffice form Terminal and it started no problem without any error message.
As suggested by Apple and Rory, I uninstalled OpenOffice completely, restarted, and reinstalled a fresh OO 4.0.1. The problem continues.
Have recovered the password files using another computer. The "bug" has not been identified or removed from my iMac. Hoping for a cure !
After running Disk Utility on Mac, this came up. Don't know if it's significant: "ACL found but not expected on “private/etc/apache2/users”"
(In reply to Robert from comment #16) > As suggested by Apple and Rory, I uninstalled OpenOffice completely, > restarted, and reinstalled a fresh OO 4.0.1. The problem continues. You must reset your profile between uninstall and reinstall.
(In reply to oooforum from comment #19) > (In reply to Robert from comment #16) > > As suggested by Apple and Rory, I uninstalled OpenOffice completely, > > restarted, and reinstalled a fresh OO 4.0.1. The problem continues. > You must reset your profile between uninstall and reinstall. Could you please clarify how this is done correctly (is this the Library, user, renaming ?).
(In reply to Robert from comment #20) > Could you please clarify how this is done correctly (is this the Library, > user, renaming ?). A very large proportion of problems are cured by deleting or renaming the OpenOffice User Profile. See:
https://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=12426
Reading bug 121086 and this one, it does not seem to be a user profile bug. I tend to think that there is a dependency problem with system libraries. Can you ran the following command on a terminal, and attach the output text file here? The command: OO_HOME=/Applications/OpenOffice.app/Contents/MacOS;for i in ${OO_HOME}/*.dylib; do otool -L $i >> ~/aoo_libs.txt;done - You may need to change the value of OO_HOME from /Applications/OpenOffice.app/Contents/MacOS to the place where OpenOffice.app is installed - the command writes to a file aoo_libs.txt in your user home directory
(In reply to Ariel Constenla-Haile from comment #23) > Reading bug 121086 and this one, it does not seem to be a user profile bug. > I tend to think that there is a dependency problem with system libraries. > > Can you ran the following command on a terminal, and attach the output text > file here? > The command: > > OO_HOME=/Applications/OpenOffice.app/Contents/MacOS;for i in > ${OO_HOME}/*.dylib; do otool -L $i >> ~/aoo_libs.txt;done > > > - You may need to change the value of OO_HOME from > /Applications/OpenOffice.app/Contents/MacOS to the place where > OpenOffice.app is installed > > - the command writes to a file aoo_libs.txt in your user home directory Tried to do this and was asked to download "Developer Tools" which I did, no response when reentered your directory address. The file is in applications but unfamiliar with how to adjust the address to get a result. Happy to try again if you can clarify for me or can submit more information for you if needed.
(In reply to Robert from comment #24) > Tried to do this and was asked to download "Developer Tools" which I did, no > response when reentered your directory address. > > The file is in applications but unfamiliar with how to adjust the address to > get a result. Happy to try again if you can clarify for me or can submit > more information for you if needed. If OpenOffice is installed in the default location, that is /Applications/OpenOffice.org.app/, then you don't need to change the command. The command is a single line (though your browser may wrap the line and show more): OO_HOME=/Applications/OpenOffice.app/Contents/MacOS;for i in ${OO_HOME}/*.dylib; do otool -L $i >> ~/aoo_libs.txt;done In the command, the variable OO_HOME is assigned the value /Applications/OpenOffice.app/Contents/MacOS If OpenOffice isn't installed in /Applications/OpenOffice.app, you have to modified this value.
(In reply to Ariel Constenla-Haile from comment #25) > (In reply to Robert from comment #24) > > Tried to do this and was asked to download "Developer Tools" which I did, no > > response when reentered your directory address. > > > > The file is in applications but unfamiliar with how to adjust the address to > > get a result. Happy to try again if you can clarify for me or can submit > > more information for you if needed. > > If OpenOffice is installed in the default location, that is > /Applications/OpenOffice.org.app/, then you don't need to change the > command. The command is a single line (though your browser may wrap the line > and show more): > > OO_HOME=/Applications/OpenOffice.app/Contents/MacOS;for i in > ${OO_HOME}/*.dylib; do otool -L $i >> ~/aoo_libs.txt;done > > In the command, the variable OO_HOME is assigned the value > /Applications/OpenOffice.app/Contents/MacOS > If OpenOffice isn't installed in /Applications/OpenOffice.app, you have to > modified this value. This command does not produce any result as written. Tried is several times but just comes back to the prompt.
(In reply to Robert from comment #26) > This command does not produce any result as written. Tried is several times > but just comes back to the prompt. as said in comment 23, the command writes to a file aoo_libs.txt in your user home directory. Open Finder and you'll find aoo_libs.txt in your home dir.
Created attachment 83869 [details] Mac Text File As requested.
since 4.1.1 no password-protected file will open. Mac OSX 10.9 terrible, can't work!
Have gone back to 4.0.1 !!! Changed "libvcl.dylib" again for solve the scrolling-bug (issue 124191): PASSWORD NOT CORRECT - FILE CANNOT BE OPENED !!!! How shall I work now? Please fix this soon !!!! (PS: last Post means 4.1.0)
Created attachment 83873 [details] aoo_libs.txt
Another report of Mac password trouble: https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=72014
And another case of Mac and Calc passwords not opening. https://forum.openoffice.org/en/forum/viewtopic.php?f=17&t=68109
(In reply to roryof from comment #32) > Another report of Mac password trouble: > https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=72014 There is indeed a real problem, though it couldn't be reproduced by any developer. My assuption that this can be a problem with system libraries might be right, but unfortunately the output of otool does not show any problem. sal/osl/unx/module.c has some debugging/tracing code that could be turned on or converted to simple printf statements. @jsc: did you change the build environment from 4.1.0 to 4.1.1? Comment 30 from Manfred seems to suggest that this bug appeared for him with the latest release but is not reproducible with >= 4.1.0
So I have to explain: This Issue first happens after upgrading to 4.1.1 (64bit). On the same machine after going back to 4.1(64bit) I could not open the files. On an other !! old Mac with 4.0.1 (32bit) I could open them and save without password. I can work with these files on the newer Mac now. But still work without password.
There was an other issue (Scrolling issue) https://issues.apache.org/ooo/show_bug.cgi?id=124191 that only infects Mac OS 10.9 and the 64 bit Version… Maybe that helps to locate the trouble.
We have 3 reports from french user forum with a similar issue. Since 4.1.1 and MacOS X 10.9, no password-protected file will open. Also, it's unable to save a password-protected file: I/O general error occurs. Seems to be a problem with x64 system and algorithm to encrypt file. This bug is a very important one and it should be set as "regression".
Another user report of the same issue. http://mail-archives.apache.org/mod_mbox/openoffice-users/201410.mbox/%3cBLU437-SMTP56074A6539FA2FACF307DAAFA10@phx.gbl%3e
(In reply to jonathandl from comment #38) > Another user report of the same issue. > > http://mail-archives.apache.org/mod_mbox/openoffice-users/201410.mbox/ > %3cBLU437-SMTP56074A6539FA2FACF307DAAFA10@phx.gbl%3e Sorry but no configuration info is available. We don't know which system and AOO version is impacted
He wrote it happens with 4.1.1 and installing 4.0.1 did not resolve this issue: <I HAVE UNINSTALL THE 4.1.1 VERSION AND INSTALL AN OTHER VERSION LIKE 4.0.1 WITHOUT SUCCES ALSO.> For shure he works with Mavericks (Mac OS 10.9) and a 64bit Version of OpenOffice Calc. Please see issue https://issues.apache.org/ooo/show_bug.cgi?id=124191 This issue happens also only with Mavericks (Mac 10.9) and the 64bit Version since 4.1 I have written a complex "App" for "record keeping" and "Payroll accounting" for my company. (Don't know in english) Without a password-protection it is useless, because the Tax office can reject it, when it did not include some special Criteria, like password-protection and others. So: Please help and fix this issue.
I use MacOSX 10.9.5 and have no problems to open an old password protected file from 2011 (can't remember the version I used to create it) with AOO 4.1.1. I created a new text password protected odt file with AOO 4.1., closed it and reopended ... works as expected.
User posted an update to the forum: 1. When saving documents, the error message is "Erreur en sauvegardant Internet-free: Erreur générale. Erreur générale d'E/S." 2. The user has a 2010 MacBook Pro that originally had Mac OS 10.9 ("Mavericks") and then updated to Mac OS "Yosemite." (In reply to oooforum from comment #39) > > Sorry but no configuration info is available. > We don't know which system and AOO version is impacted
I would like to see some information from one of the files that previously opened and now does not. An encrypted ODT (or ODS) file can be opened using a Zip utility. This will not reveal any of the encrypted data. It will reveal some details about how the encryption was done. The file I am interested in is named META-INF/manifest.xml. Please extract that file and upload it to this bugzilla issue. I don't need to know the password. It just has to be the manifest from an encrypted ("Saved with Password") file that could be opened before and cannot be opened now. There may be clues to why some installations are doing this differently. Or not. I think on seeing the manifest I can think of more useful questions to ask.
Created attachment 84114 [details] META-INF manifest.xml
I've looked at Manfred's manifest.xml, and I'll look at some of the other files, such as the one that doesn't confirm on other platforms. I don't see anything obvious just yet. I think Ariel's suspicions about a change in some dependency is likely, although it could also be an edge case that other differences have brought to the surface. Here's an unusual request. Because the situation on being able to open some of these files can be desperate, I recommend the following actions for Mac OSX users who have the problem: 1. Obtain and install the Mac release of LibreOffice 4.3. This package should install along-side Apache OpenOffice without any problems. See if the files open with the password there. (This will also be a fresh install instead of a roll-back, so that symptom should not be a factor as it seems to be with AOO.) If the files open with LibO, that is at least an immediate workaround. If the files open with LibO, we can work to figure out what difference in dependencies might account for the difference with AOO. If the file also fails to open with LibO, we need to look for a common-mode problem in both implementations. 2. If there is no joy with LibreOffice 4.3, try NeoOffice. Same challenges. 3. Confirm results here, positive or negative, so that we have more clues to this situation.
I received an update from the user with the French version of OpenOffice, with a 2010 MacBook Pro that originally had Mac OS 10.9 and now has Mac OS X "Yosemite". The files in question open just fine with LibreOffice. (In reply to orcmid from comment #45) > Here's an unusual request. Because the situation on being able to open some > of these files can be desperate, I recommend the following actions for Mac > OSX users who have the problem: > > 1. Obtain and install the Mac release of LibreOffice 4.3. This package > should install along-side Apache OpenOffice without any problems. See if > the files open with the password there. (This will also be a fresh install > instead of a roll-back, so that symptom should not be a factor as it seems > to be with AOO.) > If the files open with LibO, that is at least an immediate workaround. > If the files open with LibO, we can work to figure out what difference > in dependencies might account for the difference with AOO. > If the file also fails to open with LibO, we need to look for a > common-mode problem in both implementations.
Installed LibreOffice 4.2.7 (last stable Version): It opens all my secured Documents. Imported a template, made with OO Calc without password protection, into LibreOffice, saved it from there with password: OpenOffice Calc did not open it ("Password incorrect"), LibreOffice did the job. Thank you for this hint! (I still work with Mac OS 10.9)
I received an off-list report that LibreOffice documents created with 4.3 will roundtrip on Macintosh and fail to be opened with Apache OpenOffice 4.1.1 (or whatever the latest Macintosh release is). Those files use SHA256 (instead of SHA1) and use AES instead of Blowfish. As we already know, the files can be opened just fine on other installations of AOO 4.1.1 (such as on Windows). I think that is confirmation that there is a problem in the dependencies of Apache OpenOffice in the case of distributions on recent OS X platforms. There is a fairly lengthy tool chain in which there could be a defect, starting with how the Unicode UTF8 of the password is obtained on each platform. Beside looking into the chain of transformations that go into decryption, it may be important to check all of the ways the failure message can be reached. If there are exceptions that lead to that message, that could also be a clue. I have no expertise with the code itself, so have little else to offer.
We have two Macs with Open Office. One has the password issue (Mac Mini 5,1) and one does not (iMac 8,1). The problem has been persistant over multiple 4.X versions of OO, and with OS X 10.9 and 10.10. Tried deleting the profile, reinstalling OO, and using the profile from the working computer; but no success. A clean install was performed with the OS X 10.10 update, reloaded the user files from a Time Machine backup (OO and all related user files were deleted before making the backup). Still have the password problem after OO was reinstalled. Tonight I tried exporting the protected file from the working computer to a password protected 'Microsoft Word 97/2000/XP' format. The non-working Mini finally could open this password protected document! I hope this is a clue to help solve this issue (and for me it is a temporary work around).
This is not just a mac problem. The more I look, the more I see. Admittedly they are sporadic but they are killers. Here's mine: https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=74265&p=335855#p335855 The only connection I can think of is going from Mint Quiana -> Rebecca
I just discovered this bug on our systems. We use mac minis with Windows8 and OSX Yosemite, and just upgraded to OpenOffice4.1.1 on both platforms. The Windows8 installation handles our passworded Calc file, but the OSX installation says 'password incorrect'. LibreOffice on the OSX machine handles the passworded Calc file fine. Let me know if I can assist with any other information.
"The Password is incorrect. The file cannot be opened." Openoffice 4.1 – Calc & Writer effected. Ref: Linux OS's This is my first time of posting and I am adding my comments here as it would seem the most appropriate place. In Brief, on testing OpenOffice scalc & writer sheets in Linux, this is the situation as I have perceived it. 1. OO 4.0 works with existing password protected files and can create new password protected files. 2. OO 4.1 works with existing password protected files and can create new password protected files, except with the following proviso: CHANGING THE PROFILE PATH INFORMATION IN THE 'PROFILE.INI' FILES IN EITHER MOZILLA 'FIREFOX' OR 'THUNDERBIRD' CAUSES PASSWORD ERRORS, WHEN USING OO 4.1, SUCH THAT PASSWORD PROTECTED FILES CANNOT BE ACCESSED OR CREATED.. OS's tried: 32 & 64 bit ubuntu based OS's: Mint xfce, Netrunner KDE, xubuntu xfce and Manjaro xfce 64bit only. All with the same result (2 above). PC Specs: Processor: AMD A10-5800K APU 64 bit (with Radeon HD Graphics 3.80GHz) RAM: 16.0 GB Dual-Channel DDR3 @ 803MHz Graphics used: 1023MB NVIDIA GeForce GTS 450 (ASUStek Computer Inc) Motherboard: ASUSTeK COMPUTER INC. F2A85-M LE (FM2 ) The following is a more full explanation of my experience with this problem. I have been a Linux user for 3-4 years, currently using xubuntu 15 64bit, but have experimented with other versions of linux. I have recently discovered what appears to be a very extraordinary connection between OpenOffice 4.1 password errors and both Mozilla Firefox & Thunderbird 'profile.ini' files. I had been using Netrunner 14 LTS and/or xubuntu 14 LTS for some while and could never upgrade from OpenOffice 4.0 to 4.1. Every time I tried I would get password errors. I could never open existing, or create new, password protected files. However, I recently tried out Netrunner 15 & Xubuntu 15 and discovered that both would (at least initially) allow OO 4.1 to work correctly. OO 4.1 allowed access to existing password protected files and would create new protected files. I was impressed with xubuntu 15, so decided to migrate to it. I installed everything I needed in Xubuntu 15 including OO 4.1 and Mozilla Firefox and Thunderbird. Everything was working correctly OO 4.1 was working with password protected with no errors. Now comes the twist. I normally have both my Firefox & Thunderbird profiles stored on a separate HDD partition from my OS, so that I can access them from whichever OS I am running at any given time. But, at this point in my setting up of xubuntu, both Firefox & Thunderbird were accessing there default, as installed, profiles located on my Xubuntu 15 user home partition. The default 'profile.ini' files located in my '/home/[username]/.mozilla/firefox/' & '/home/[username]/.thunderbird' folders being unchanged. Example: Default 'profile.ini', as set up by Firefox on installation: [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=1 Path=2nqw1pp9.default Default=1 n.b. 1. The profile folder name '2nqw1pp9.default' is the profile name of the profile being accessed. However, this can be any name. 2. Firefox & Thunderbird 'profile.ini' files have the same structure. So, as a final step in the migration to xubuntu, I amended the 'profile.ini' files to let Firefox & Thunderbird access my profiles. Example: Amended 'profile.ini' file: [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=0 Path=/[user path]/2nqw1pp9.default Default=1 n.b. The only items changed are: 1. IsRelative= is changed to 0. 2. 'Path=' is amended to include the '/[user path]/' to the my profiles. After making the path changes I tried opening my OO password protected files and all failed. I could no longer open existing password protected or create new password protected files (calc or writer). Fortunately, the Firefox & Thunderbird 'profile.ini' files were the last changes I had made, so I reset them back to the default location and tried again. OO4.1 now worked properly with passwords again. After trial and error, it seems that the 'IsRelative' setting in the 'profile.ini' file is unimportant. What seems to be critical is the 'Path=' information. I tried several times amending the 'Path=' and every time I added a path, in either one of the Firefox or Thunderbird 'profile.ini' files, passwords failed to work in OO 4.1. It also doesn't seem to matter what the path is just as long as a '/[user path]/' is placed in front of the profile name. I have also tried amending the 'profile.ini' paths in Netrunner 15 (where previously OO 4.1 was working correctly) and in Manjaro xfce. Again, after inserting a '[user path]' in front of the profile name, I experienced exactly the same password errors. This problem occurred in both 32 bit & 64 bit OS's I tried. It also appears to be solely a problem with OO 4.1. When using OO 4.0, amending the Mozilla 'profile.ini' files has no adverse effects at all. I do hope this is useful. Unfortunately I am going into hospital for an operation in the next few days so may not be able to respond to any questions for some while, but will answer when I can. Paul
@Paul Interesting. I have this issue with 4.1 under Linux Mint 17 64 bit where the profiles for TB and FX stored on another HDD so to that extent I can confirm what is being said. Further, it is not a problem with LibreOffice which I now use in place of OO.
Brilliant work Paul. Corruption of ~/.mozilla/firefox/profiles.ini (eg. changing Path to an invalid value) reproducibly causes "The password is incorrect. The file cannot be opened" to appear in AOO 4.1.1 on Ubuntu 14.04 32-bit. Can someone with a Mac on which this problem appears attach their ~/Library/Application Support/Firefox/Profiles/profiles.ini and/or ~/Library/Mozilla/Firefox/Profiles/profiles.ini? I closed AOO, corrupted that file, opened Calc, and compared /proc/<pid>/maps before and after trying (and failing) to open an encrypted Writer document to see what changed in terms of loaded libraries. Not surprisingly, most of them were libnss libraries from the Mozilla project (below). Luckily it should be possible to fix this just by reimplementing small bits of main/xmlsecurity using another encryption library instead of libnss, or maybe even just by building AOO without some Mozilla dependencies. I will do some testing later. $ diff -u /tmp/before /tmp/after --- /tmp/before 2015-09-28 16:13:32.598992999 +0200 +++ /tmp/after 2015-09-28 16:14:35.439488250 +0200 @@ -1,6 +1,38 @@ 08048000-0804a000 r-xp 00000000 08:01 546481 /opt/openoffice4/program/soffice.bin 0804a000-0804b000 rw-p 00001000 08:01 546481 /opt/openoffice4/program/soffice.bin -08bf2000-090c8000 rw-p 00000000 00:00 0 [heap] +08bf2000-090f9000 rw-p 00000000 00:00 0 [heap] +a7e2d000-a804d000 rw-p 00000000 00:00 0 +a804d000-a80a8000 r-xp 00000000 08:01 526284 /opt/openoffice4/program/libnssckbi.so +a80a8000-a80b8000 rw-p 0005a000 08:01 526284 /opt/openoffice4/program/libnssckbi.so +a80b8000-a8104000 r-xp 00000000 08:01 546505 /opt/openoffice4/program/libfreebl3.so +a8104000-a8105000 rw-p 0004c000 08:01 546505 /opt/openoffice4/program/libfreebl3.so +a8105000-a8109000 rw-p 00000000 00:00 0 +a8109000-a8128000 r-xp 00000000 08:01 546507 /opt/openoffice4/program/libnssdbm3.so +a8128000-a8129000 rw-p 0001e000 08:01 546507 /opt/openoffice4/program/libnssdbm3.so +a8129000-a819c000 r-xp 00000000 08:01 526341 /opt/openoffice4/program/libsqlite3.so +a819c000-a819e000 rw-p 00073000 08:01 526341 /opt/openoffice4/program/libsqlite3.so +a819e000-a81d1000 r-xp 00000000 08:01 546510 /opt/openoffice4/program/libsoftokn3.so +a81d1000-a81d2000 rw-p 00033000 08:01 546510 /opt/openoffice4/program/libsoftokn3.so +a81d2000-a81dc000 r-xp 00000000 08:01 526543 /opt/openoffice4/program/mozbootstrap.uno.so +a81dc000-a81dd000 rw-p 00009000 08:01 526543 /opt/openoffice4/program/mozbootstrap.uno.so +a81dd000-a81df000 r-xp 00000000 08:01 526350 /opt/openoffice4/program/libplds4.so +a81df000-a81e0000 rw-p 00001000 08:01 526350 /opt/openoffice4/program/libplds4.so +a81e0000-a81fc000 r-xp 00000000 08:01 546515 /opt/openoffice4/program/libnssutil3.so +a81fc000-a81ff000 rw-p 0001c000 08:01 546515 /opt/openoffice4/program/libnssutil3.so +a81ff000-a8200000 rw-p 00000000 00:00 0 +a8200000-a822f000 r-xp 00000000 08:01 546506 /opt/openoffice4/program/libnspr4.so +a822f000-a8230000 rw-p 0002f000 08:01 546506 /opt/openoffice4/program/libnspr4.so +a8230000-a8232000 rw-p 00000000 00:00 0 +a8232000-a833b000 r-xp 00000000 08:01 546514 /opt/openoffice4/program/libnss3.so +a833b000-a8340000 rw-p 00108000 08:01 546514 /opt/openoffice4/program/libnss3.so +a8340000-a83ee000 r-xp 00000000 08:01 526555 /opt/openoffice4/program/libxsec_xmlsec.so +a83ee000-a83f4000 rw-p 000ae000 08:01 526555 /opt/openoffice4/program/libxsec_xmlsec.so +a83f4000-a8424000 rw-p 00000000 00:00 0 +a8424000-a8e0b000 r-xp 00000000 08:01 526472 /opt/openoffice4/program/libsw.so +a8e0b000-a8e85000 rw-p 009e7000 08:01 526472 /opt/openoffice4/program/libsw.so +a8e85000-a8e89000 rw-p 00000000 00:00 0 +a8e89000-a8e94000 r-xp 00000000 08:01 528606 /opt/openoffice4/program/libswd.so +a8e94000-a8e95000 rw-p 0000b000 08:01 528606 /opt/openoffice4/program/libswd.so a8e95000-a8ea3000 r-xp 00000000 08:01 526593 /opt/openoffice4/program/updatefeed.uno.so a8ea3000-a8ea4000 rw-p 0000d000 08:01 526593 /opt/openoffice4/program/updatefeed.uno.so a8ea4000-a8eca000 r--s 00000000 08:01 2096 /usr/share/fonts/truetype/liberation/LiberationSerif-Regular.ttf @@ -128,9 +160,11 @@ acb6c000-acb6d000 rw-p 0006b000 08:01 1835366 /usr/lib/i386-linux-gnu/libcups.so.2 acb6d000-acd6d000 rw-s 00000000 00:04 6651928 /SYSV00000000 (deleted) acd6d000-acd6e000 ---p 00000000 00:00 0 -acd6e000-ad56e000 rw-p 00000000 00:00 0 +acd6e000-ad56e000 rw-p 00000000 00:00 0 [stack:9190] ad56e000-ad5a0000 r-xp 00000000 08:01 526568 /opt/openoffice4/program/libcurl.so.4 ad5a0000-ad5a1000 rw-p 00032000 08:01 526568 /opt/openoffice4/program/libcurl.so.4 +ad5a1000-ad5a4000 r-xp 00000000 08:01 526276 /opt/openoffice4/program/libplc4.so +ad5a4000-ad5a5000 rw-p 00002000 08:01 526276 /opt/openoffice4/program/libplc4.so ad5a5000-ad5ae000 r-xp 00000000 08:01 526270 /opt/openoffice4/program/libscd.so ad5ae000-ad5af000 rw-p 00009000 08:01 526270 /opt/openoffice4/program/libscd.so ad5af000-ad5bd000 r-xp 00000000 08:01 526607 /opt/openoffice4/program/libfileacc.so
as requested (Mac OSX 10.10): ~/Library/Application Support/Firefox/profiles.ini not on my machine: ~/Library/Application Support/Firefox/Profiles/profiles.ini and ~/Library/Mozilla/Firefox/Profiles/profiles.ini Manfred
Created attachment 84963 [details] App-Support_profiles.ini
Thank you Manfred. It looks normal. Maybe the mozilla libraries are looking in the wrong place for that file or they are breaking somewhere else? Without a Mac, it's hard to tell. You could check whether it's looking for the right file by tracing system calls with strace/[d]truss/dtrace but I am not sure how to run those on a Mac... When I try open an encrypted file with a debug version of AOO, I get an error dialog saying: Error: Can not create a SHA-256 digest! From File: AOO/main/comphelper/source/misc/storagehelper.cxx at Line 451 followed by that password incorrect error. Which comes from the method OStorageHelper::CreatePackageEncryptionData() which is trying to instantiate "com.sun.star.xml.crypto.NSSInitializer" and gives that error on failure. The com.sun.star.xml.crypto.NSSInitializer is implemented in main/xmlsecurity. There is code that reads the Firefox / Thunderbird / other profiles. Not clear where it's breaking. There is a plan to replace nss, which may help this.
Created attachment 84969 [details] Implement digest functions using openssl This patch implements xmlsecurity's digest functions using openssl instead of nss, and gets AOO to load encrypted files despite a corrupt Firefox profile. Can someone please test it on MacOS? You have to build with both nss and openssl enabled, first without the patch to verify it's still broken, then with it to see if the patch helps.
do we have a document for testing that can't be open? The doc from #4 can be open with AOO 4.1.1 and see my comment #41. I am currently building Damjan's patch and will report son if it works
(In reply to jsc from comment #59) > do we have a document for testing that can't be open? The doc from #4 can be > open with AOO 4.1.1 and see my comment #41. > > I am currently building Damjan's patch and will report son if it works jsc: do you have any Mozilla products (Firefox, Thunderbird, etc.) installed on that Mac? If so, please remove them completely, delete all profiles.ini files (eg. ~/Library/Application Support/Firefox/Profiles/profiles.ini and ~/Library/Mozilla/Firefox/Profiles/profiles.ini and other such for Thunderbird etc.), and then try again. I suspect that the error happens on Macs without Mozilla products and without the MOZILLA_CERTIFICATE_FOLDER environment variable set.
sure I have Firefox and Thunderbird installed but when I rename their related folder it still work. I think I checked this before
(In reply to jsc from comment #61) > sure I have Firefox and Thunderbird installed but when I rename their > related folder it still work. I think I checked this before The profiles are only read once and then reused until AOO exits, so AOO needs a complete restart too.
(In reply to damjan from comment #60) > I suspect that the error happens on > Macs without Mozilla products and without the MOZILLA_CERTIFICATE_FOLDER > environment variable set. No, it happens to me and I use Firefox since a few years… The easiest way to find an answer: What in AOO 4.1.1 has been changed to open secured docs, compared to 4.1.0? (Mac-Version only…) Or: LibreOffice opens the secured docs. Where is the difference between both apps in opening password-secured documents? (Mac-Version only…)
good job Damjan, I built trunk on MacOS with your patch and was able to save and load a document with password. Also was able to load documents created with AOO 3.4, the attached one from Ariel.
Created attachment 84973 [details] test_password_aootrunk_openssl.odt (pw test1234) new pass protrected document create on MacOS with a fresh build including the attached patch to replace nss with openssl. Password is test1234
(In reply to jsc from comment #64) > good job Damjan, I built trunk on MacOS with your patch and was able to save > and load a document with password. Also was able to load documents created > with AOO 3.4, the attached one from Ariel. Thank you. You were saying it worked for you even without my patch though? So we don't know if it fixes anything for other Mac users?
*** Issue 126739 has been marked as a duplicate of this issue. ***
Tried installing LibreOffice both Still and Fresh versions and on my iMac with OS X 10.10.5 Yosemite the software went through the verifying process and then refused to open. My iMac was also seriously slowed down. So no use. Shall try NeoOfice and see if that works. HUGH (In reply to orcmid from comment #45) > I've looked at Manfred's manifest.xml, and I'll look at some of the other > files, such as the one that doesn't confirm on other platforms. > > I don't see anything obvious just yet. I think Ariel's suspicions about a > change in some dependency is likely, although it could also be an edge case > that other differences have brought to the surface. > > Here's an unusual request. Because the situation on being able to open some > of these files can be desperate, I recommend the following actions for Mac > OSX users who have the problem: > > 1. Obtain and install the Mac release of LibreOffice 4.3. This package > should install along-side Apache OpenOffice without any problems. See if > the files open with the password there. (This will also be a fresh install > instead of a roll-back, so that symptom should not be a factor as it seems > to be with AOO.) > If the files open with LibO, that is at least an immediate workaround. > If the files open with LibO, we can work to figure out what difference > in dependencies might account for the difference with AOO. > If the file also fails to open with LibO, we need to look for a > common-mode problem in both implementations. > > 2. If there is no joy with LibreOffice 4.3, try NeoOffice. Same challenges. > > 3. Confirm results here, positive or negative, so that we have more clues > to this situation.
NeoOffice worked perfectly so I decided to buy the Apple App store version. Many thanks. HUGH (In reply to Hugh Beevor from comment #68) > Tried installing LibreOffice both Still and Fresh versions and on my iMac > with OS X 10.10.5 Yosemite the software went through the verifying process > and then refused to open. My iMac was also seriously slowed down. So no use. > Shall try NeoOfice and see if that works. HUGH > > (In reply to orcmid from comment #45) > > I've looked at Manfred's manifest.xml, and I'll look at some of the other > > files, such as the one that doesn't confirm on other platforms. > > > > I don't see anything obvious just yet. I think Ariel's suspicions about a > > change in some dependency is likely, although it could also be an edge case > > that other differences have brought to the surface. > > > > Here's an unusual request. Because the situation on being able to open some > > of these files can be desperate, I recommend the following actions for Mac > > OSX users who have the problem: > > > > 1. Obtain and install the Mac release of LibreOffice 4.3. This package > > should install along-side Apache OpenOffice without any problems. See if > > the files open with the password there. (This will also be a fresh install > > instead of a roll-back, so that symptom should not be a factor as it seems > > to be with AOO.) > > If the files open with LibO, that is at least an immediate workaround. > > If the files open with LibO, we can work to figure out what difference > > in dependencies might account for the difference with AOO. > > If the file also fails to open with LibO, we need to look for a > > common-mode problem in both implementations. > > > > 2. If there is no joy with LibreOffice 4.3, try NeoOffice. Same challenges. > > > > 3. Confirm results here, positive or negative, so that we have more clues > > to this situation.
Hello, (In reply to damjan from comment #58) > Created attachment 84969 [details] > Implement digest functions using openssl FWIW, I encountered this problem under FreeBSD, using a AOO 4.1.2 build from the ports tree. The patch applied correctly to the sources and solved the problem for me. Thank you, Damjan! FYI, I submitted your patch to the FreeBSD Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206234
(In reply to Arrigo Marchiori from comment #70) > Hello, > > (In reply to damjan from comment #58) > > Created attachment 84969 [details] > > Implement digest functions using openssl > > FWIW, I encountered this problem under FreeBSD, using a AOO 4.1.2 build from > the ports tree. > The patch applied correctly to the sources and solved the problem for me. > > Thank you, Damjan! > > FYI, I submitted your patch to the FreeBSD Bugzilla: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206234 No problem, thank you Arrigo for testing and reporting back! Are you absolutely certain it's my patch that fixed it, and not something else? Can you please recompile AOO from scratch, exactly like you did to get it to work, but WITHOUT my patch, and verify the problem still happens?
(In reply to damjan from comment #71) > (In reply to Arrigo Marchiori from comment #70) > > Hello, > > > > (In reply to damjan from comment #58) > > > Created attachment 84969 [details] > > > Implement digest functions using openssl > > > > FWIW, I encountered this problem under FreeBSD, using a AOO 4.1.2 build from > > the ports tree. > > The patch applied correctly to the sources and solved the problem for me. > > > > Thank you, Damjan! > > > > FYI, I submitted your patch to the FreeBSD Bugzilla: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206234 > > No problem, thank you Arrigo for testing and reporting back! > > Are you absolutely certain it's my patch that fixed it, and not something > else? Can you please recompile AOO from scratch, exactly like you did to get > it to work, but WITHOUT my patch, and verify the problem still happens? Just verified. Without your patch, password-protected files cannot be created nor opened. With your patch, everything works smoothly. FYI, nss version on my system is 3.21.0 (also installed from the FreeBSD ports tree).
(In reply to Arrigo Marchiori from comment #72) > (In reply to damjan from comment #71) > > (In reply to Arrigo Marchiori from comment #70) > > > Hello, > > > > > > (In reply to damjan from comment #58) > > > > Created attachment 84969 [details] > > > > Implement digest functions using openssl > > > > > > FWIW, I encountered this problem under FreeBSD, using a AOO 4.1.2 build from > > > the ports tree. > > > The patch applied correctly to the sources and solved the problem for me. > > > > > > Thank you, Damjan! > > > > > > FYI, I submitted your patch to the FreeBSD Bugzilla: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206234 > > > > No problem, thank you Arrigo for testing and reporting back! > > > > Are you absolutely certain it's my patch that fixed it, and not something > > else? Can you please recompile AOO from scratch, exactly like you did to get > > it to work, but WITHOUT my patch, and verify the problem still happens? > > Just verified. Without your patch, password-protected files cannot be > created nor opened. With your patch, everything works smoothly. > > FYI, nss version on my system is 3.21.0 (also installed from the FreeBSD > ports tree). Thank you, that helps a lot. Now I know for sure NSS is failing somewhere. If it's something in your Mozilla profile that's breaking it, you might be able to get it to work without my patch by stopping all applications that are using NSS (usually in the form of libnss3.so) - these are all Mozilla applications like Firefox and Thunderbird, OpenOffice, LibreOffice and any others. Then move or rename your ~/.mozilla directory (don't delete - it contains your Firefox bookmarks and settings!). Then start OpenOffice and try again. If it works, you could mix files between the old and new directories and eventually narrow it down to the specific file that causes the problem. Maybe we could eventually learn something from that file... The thing is, we shouldn't be using a library that fragile, that commonly breaks in the field with disastrous consequences, even for something simple like calculating cryptographic digest functions, and that we have no easy way to debug or fix. Maybe once we better understand what's wrong, and can reproduce the problem and test, we can use NSS with different settings so its more resilient, but its license doesn't really suit us either, so an alternative would be welcome. I've started an email thread on our dev@apache.openoffice.org list to discuss possibilities.
(In reply to damjan from comment #73) [...] > If it's something in your Mozilla profile that's breaking it, you might be > able to get it to work without my patch by stopping all applications that > are using NSS (usually in the form of libnss3.so) - these are all Mozilla > applications like Firefox and Thunderbird, OpenOffice, LibreOffice and any > others. Then move or rename your ~/.mozilla directory (don't delete - it > contains your Firefox bookmarks and settings!). Then start OpenOffice and > try again. If it works, you could mix files between the old and new > directories and eventually narrow it down to the specific file that causes > the problem. Maybe we could eventually learn something from that file... I am using OpenOffice, Firefox an Thunderbird. I stopped all of them, and renamed the folders: ~/.openoffice.org ~/.mozilla ~/.thunderbird The error was still there: after reconfiguring OpenOffice for my user, I was still unable to save and open password-protected files. Maybe it is something else? > The thing is, we shouldn't be using a library that fragile, that commonly > breaks in the field with disastrous consequences, even for something simple > like calculating cryptographic digest functions, and that we have no easy > way to debug or fix. FWIW I totally agree with you on this. :-) I am actually a bit puzzled by the fact that there is no error reporting. I tried to compile a debug-enabled AOO some days ago and got a somewhat cryptic error log (I am now going to attach it). > Maybe once we better understand what's wrong, and can > reproduce the problem and test, we can use NSS with different settings so > its more resilient, but its license doesn't really suit us either, so an > alternative would be welcome. I've started an email thread on our > dev@apache.openoffice.org list to discuss possibilities. I am not sure I can contribute to this topic. Office programs are not my cup of tea, I am sorry.
Created attachment 85251 [details] Log from a (supposedly) debug build showing an exception ``bubbling up'' This log file was produced in the ~/.openoffice.org/4/user/temp directory by a (supposedly) debug-enabled build of AOO 4.1.2 under FreeBSD. I cannot remember if it logs a failed open or save attempt... Please tell me if I shall provide other information like this, and how.
(In reply to Arrigo Marchiori from comment #75) > Created attachment 85251 [details] > Log from a (supposedly) debug build showing an exception ``bubbling up'' > > This log file was produced in the ~/.openoffice.org/4/user/temp directory by > a (supposedly) debug-enabled build of AOO 4.1.2 under FreeBSD. > > I cannot remember if it logs a failed open or save attempt... > Please tell me if I shall provide other information like this, and how. Your log looks like a save attempt but it's not very revealing. No useful responses to my email have been received yet, so I'm not sure what direction to take to fix this. I think NSS was chosen over alternatives due to (1) the fact it is FIPS 140 certified, (2) it provides root CA certificates we use for validating digital signatures, and (3) it provides management of personal digital certificates via the settings in Firefox/Thunderbird, so you can set them up once there, and have them work across all applications on your system. On Windows, AOO will use Microsoft's MS Crypto API for (2) and (3) instead, but other platforms don't have something like that, so Mozilla is used as the next best thing. Thus I am not sure replacing NSS is a viable option any more. OpenSSL doesn't provide its own root CA certificates, nor any GUI for managing certificates, nor a system wide database of personal digital certificates. Java has its own root CA certificates, but I don't think there's a system-wide personal digital certificate store, nor a GUI for managing anything; Java is also optional to AOO. We are left with either replacing the other cryptographic functions of NSS with alternatives while leaving it for use in digital signatures (so when it breaks you can't sign or verify digital signatures, but you can hash and encrypt/decrypt), possibly losing FIPS 140 validity in the process (unless Java is used, which seems to have been FIPS 140 certified, but I don't know whether "This document is encrypted, please install Java to open it" will fly), or fixing NSS. Let's try and fix NSS first. There's a BASIC macro that detects Mozilla profiles and prints out settings on https://wiki.openoffice.org/wiki/Certificate_Detection. On FreeBSD where I can reproduce your problem, it detects my Firefox profile, then gives an error about creating a SHA-256 digest, and then claims the right password is wrong. In the code, the method ONSSInitializer::getCipherContext() in main/xmlsecurity/source/xmlsec/nss/nssinitializer.cxx calls initNSS() which fails. Why? initNSS() calls InitNSSInitialize(), then its operator(), which calls nsscrypto_initialize() which returns false (a failure) for bInitialized, yet true for bNSSInit. nsscrypto_initialize() is a complicated function, but it calls xmlsec_trace() to log errors, which needs a debug build and the environment variable XMLSECURITY_TRACE=1, with which I get: [xmlsecurity] Using profile: /path/to/CORRUPT/PROFILE [xmlsecurity] FAILED to load the new root certificate module "Root Certs for Apache OpenOffice" contained in /AOO/main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/../program/libnssckbi.so Adding fprintf(stderr, "...\n"); statements all over the show and tracing execution through the complicated nsscrypto_initialize() function critical to this bug, led me to see how: * The SYSTEM_MOZILLA define doesn't exist; it hasn't existed since SeaMonkey's removal in AOO 4.1.0. But because the "if (!SECMOD_HasRootCerts())" section is inside a "#if defined SYSTEM_MOZILLA", it is skipped, and loading of libnssckbi is always attempted, even when it's unnecessary because we already have the root certificates. * The path to libnssckbi is: - "nssckbik" + SAL_DLLEXTENSION on OS/2 - "libnssckbi" + SAL_DLLEXTENSION with SYSTEM_MOZILLA defined (ie. never) - "${OOO_BASE_DIR}/program/libnssckbi" + SAL_DLLEXTENSION otherwise which means, on non-OS/2 platforms, ***ONLY*** when we're using the ***INTERNAL*** NSS library (causing NSS and its libraries to build and ship with AOO in opeonoffice4/program) can NSS initialize! Using the system NSS causes AOO to still look for libnssckbi.so in its own openoffice4/program directory, where it won't find it!!! Let me build AOO with and without its internal NSS to confirm, and then work out patches for the above issues.
Patch committed in revision 1724971, resolving fixed. #i125431# "The Password is incorrect. The file cannot be opened." Fix a serious cross-platform regression caused during SeaMonkey's removal and first released in version 4.1.0, where all features provided by NSS (like opening and saving encrypted documents, digital signatures, etc.) were failing. SYSTEM_MOZILLA doesn't exist any more, yet was being used to check whether to skip loading nssckbi when SECMOD_HasRootCerts() is true, so we were always attempting to load it even when not necessary. Also with SYSTEM_MOZILLA skipping loading it from the system path, we were always trying to load it from "${OOO_BASE_DIR}/program/libnssckbi.so" even when it wasn't there because --with-system-nss was passed to ./configure. This patch fixes the above problems by using SYSTEM_NSS instead of SYSTEM_MOZILLA, which actually exists, now both skipping loading nssckbi when unnecessary, and loading it from the right place when necessary.
(In reply to damjan from comment #77) > Patch committed in revision 1724971, resolving fixed. Damjan, thank you for the commit. I could apply it to my sources and build AOO. Now I am at your point from September, last year. :-/ As Paul noted in comment #52, the culprit seems to be the "IsRelative" entry in the profile files. Even if the value of the "IsRelative" option is zero, the "MozProfile" macro (from your comment #76) shows that the absolute path of the home directory is prepended to the value of the "Path" option. To explain my point better, here is my .mozilla/profiles.ini: [General] StartWithLastProfile=1 [Profile0] Name=default-1416909684611 IsRelative=0 Path=/usr/home/arrigo/.mozilla/firefox/shavgc0x.default-1416909684611 Default=1 But the MozProfile macro outputs: Firefox: Profile name: default-1416909684611 Profile path: /home/arrigo/.mozilla/firefox//usr/home/arrigo/.mozilla/firefox/shavgc0x.default-1416909684611 The double slash between "firefox" and "usr" looks to me like a rough string concatenation, but I am speculating. At this point, I am sorry to report you that for me the problem is not fixed, unless I change Firefox's profiles.ini. In theory, the file should be ok because Firefox starts and runs well. And the initial patch that disables NSS is still the only bullet-proof solution for me. Do you think that this bug is still worth investigation? Or maybe you solved this in a previous commit on the AOO repository? I could not find anything about it, in the history of this bug, after your comment #58 with the ``anti-nss'' patch. Thank you for your work so far.
Created attachment 85256 [details] Proposed patch to enable correct interpretation of `isRelative' option This patch should render the `isRelative' option effective, when found in Mozilla's profiles.ini files.
Just for Information: Have been to LibreOffice, because it could open my protected files, since end of 2014. Had zipped my last Version of AOO = AOO412m3(Build:9782) - Rev. 1709696 Worked with LibreOffice 4.4.2 till now with LO 5.0.4.2. Unzipped my old AOO 4.1.2 just for a test and it opens the password protected files without any trouble.
(In reply to Arrigo Marchiori from comment #79) > Created attachment 85256 [details] > Proposed patch to enable correct interpretation of `isRelative' option > > This patch should render the `isRelative' option effective, when found in > Mozilla's profiles.ini files. Brilliant work Arrigo, thank you so much! Couldn't have been easy to find. I've committed your patch in r1726068: #i125431# "The Password is incorrect. The file cannot be opened." Fix handling of the "isRelative" option in Mozilla's profiles.ini files. Patch by: Arrigo Marchiori <ardovm at yahoo dot it> Review by: me
Twice now, I have created .ods password protected spreadsheets. In both cases after some amount of time, the password stopped working without any change to it on my part. The first time I wasn't that far along, so I just restarted my work, but this time, it is a more important file. I know exactly what the password is, and I never changed it. I had no issue opening the file until a few days ago and have tried many times to access the file since with the correct password to make sure I couldn't be making typos or using caps lock. I tried upgrading my version of Open Office and now have the most current version, 4.1.2 installed on OSX 10.9.5. It's obviously frustrating knowing what the password is and still being locked out of the file. It contains critical data, which is why I password protected it in the first place. I tried the first solution posted, and when I tried to save a new file with a password I got the same error mentioned above. I was able to access the file with LibreOffice, but still can't with OO. Is there anything I can do to get this file usable with OO again? Should I remove the password protection? Thanks !! https://www.quora.com/What-is-RedGage-com
(In reply to Redfred Garett from comment #82) > I tried upgrading my version of Open Office and now have the most current > version, 4.1.2 installed on OSX 10.9.5. It's obviously frustrating knowing > what the password is and still being locked out of the file. It contains > critical data, which is why I password protected it in the first place. > > I tried the first solution posted, and when I tried to save a new file with > a password I got the same error mentioned above. I was able to access the > file with LibreOffice, but still can't with OO. > > Is there anything I can do to get this file usable with OO again? Should I > remove the password protection? There is a problem with OSX versions and Firefox that prevent the encryption/decryption working properly. Although this issue is identified as Resolved, that does not mean any repair has been issued and confirmed, unfortunately. The complication is that the defect is related to a run-time dependency on encryption services from a third party. Meanwhile, Comment 45 offers one workaround. Comment 81 is the assumption that we have a fix, although it is not in any distributed code yet. What is required is a new AOO release that gets around that dependency on MacOSX. An alternative might be some sort of hotfix or repair tool that can be applied. The last has not been investigated. I have, however, raised the priority of this issue since it effectively constitutes grave data loss.
Hello, it looks like that this fix was not included in release 4.1.3? Could you please explain why?
(In reply to Arrigo Marchiori from comment #84) > Hello, > > it looks like that this fix was not included in release 4.1.3? Could you > please explain why? Mainly because fixes from trunk are applied to the release branch only on demand, by requesting release blocker status. Concerning this bug, IMO it has been hijacked by different bugs, the original one being a MacOSX report; it seems that we have no confirmation from any Mac user that their problem was caused by an absolute path in Mozilla's profile.ini.
I first posted my experiences with this 'Open Office 4.1' password issue, for various Linux systems, on 24/08/15. Since then I have been keeping an eye open to see if this has been resolved. I am currently using 'xubunutu 18 LTS' and keep trying every release update for Openoffice Linux, but so far the issue has not been fixed. I have tried 'LibreOffice' and the password problem is not an issue. However, for my use, I prefer 'Openoffice' for many reasons and also everytime I have tried 'Libre', my comprehensive calc sheets fail in some way or another. I note the comments of 17/10/2016, about this being posted as a Mac problem. However, when posting I did not appreciate this. I would very much like to see this issue resolved. Can you tell me whether there is any progress towards releasing a Linux bug fix in an update in the near future. If the situation is that this fix will not be applied based on this being reported as a Mac issue, I am happy to re-post it as a specific bug report for linux.
@Paul: did you read the target? Fixed with next 4.2.0
Sorry I did not notice the target of 4.2. However, there does not appear to be a release date for this version. I have realised that there is a work-around for anyone still having this problem. As mentioned in my original posting the problem as I have seen it, on Linux OS's, is when setting of the 'IsRelative=0', in the firefox 'profiles.ini' file, which is required when 'Path=' points to the external path of my firefox profile. This profile being on a separate hard-drive to my linux OS. The work-around is to create a 'sym-link', in the same folder as the Firefox 'profiles.ini' file, which points to the Firefox profile. The profiles.ini 'Path=' is set to point to the created sym-link and 'IsRelative' is then set to '=1'. This has resolved the problem for me and I have now been able to update Openoffice from '4.0.1' to the latest 4.1 and no longer have the password open error.
(In reply to Paul from comment #88) > However, there does not appear to be a release date for this version. Well, this project is based on volunteers So you can participate for QA Test: https://openoffice.apache.org/get-involved.html
Cherry-picked for AOO 4.1.8 with: https://github.com/apache/openoffice/commit/f27fad259a88acef21ba95dc702ebd620d3a5f56