I've run into this same problem on AOOo 3.4.1 on OS X (10.6.8).

I have a Calc file created under a (much) older version of OOo (pre-Apache), probably in the 2.x series. I had no problems opening that file with AOOo prior to 3.3 (not sure about 3.3 itself, though), and can open it with every version of NeoOffice I've ever used. But it does not open in AOOo 3.4.1 -- when I type the (correct!) password, I get "The password is incorrect. The file cannot be opened."

FWIW, this also affects LibreOffice 3.5.3.2, so the problem exists at least as far back as the version of the underlying codebase from which that version LO was forked.

Since this seems to affect all password-protected documents, it seems like it should be a fairly high priority bug -- especially the only obvious workaround, at least for now, is to keep multiple versions around just to open those files.

*** Issue 121545 has been marked as a duplicate of this issue. ***

Updated Component.  Was listed as website 'www', and should be product 'code'.

I am not able to verify this on Windows XP.

I created 6 documents in OpenOffice 3.3.0: in the three ODF formats (odt, ods, odp) as well as the three Microsoft binary formats (doc, xls, ppt).  All were saved with a password.  I was able to open all of them in AOO 3.4.0 and AOO 3.4.1.

The one bug I did see was that PPT files were saved without a password in OOo 3.3.0.

But I wonder if there is a MacOS-specific bug with reading 3.3.0 password-protected documents?

I will attach the test documents I used.  They open fine on AOO 3.4.1 on Windows XP.  I'd love to know if the same documents fail to open on MacOS.

Created attachment 80202 [details]
ODT file created in OOo 3.3.0, password="password"

Created attachment 80203 [details]
ODS file created in OOo 3.3.0, password="password"

Created attachment 80204 [details]
ODP file created in OOo 3.3.0, password="password"

Hello world.

But in 3.4.1, "The password is incorrect.  The file cannot be opened."

Created attachment 80206 [details]
Mac OS X Error

Cannot open password protected files in 3.4 on a Mac.

Created attachment 80207 [details]
Mac OS X Save With Password Error

AOO 3.4.1 cannot save files with a password on a Mac

(In reply to comment #8)
> Hello world.
> 
> But in 3.4.1, "The password is incorrect.  The file cannot be opened."

Could you clarify?  Are you saying that you received an error but the file then opened and showed you "Hello world" ???

I cannot open or save files with passwords in 3.4, just as I posted in September 2012.

As a result, I continue to use version 3.3.  I opened your files in 3.3 with the password to confirm they opened, and read the text.

I downloaded the v3.4.1 DMG file, and posted the error message I got when opening the file. As the message says, "The file cannot be opened" in v3.4

For completeness, I also posted the error message when I attempted to save a file with a password in 3.4

I can't confirm this error. I downloaded the 3.3 odt from Rob, opened it, changed it and saved it under a new name with anew password with AOO 3.4.1 on MacOS (10.7.5)

I've replicated the error on three OS X 10.8 machines over the past few months. I do have one iMac running 10.7, and I will try it there tonight. Note that my first posting describes how I previously encountered the error in 10.7 however. 

Based on comments, this has already been replicated by others.

Thanks, Ernie.  The screenshot suggests something is going on, certainly.  No one is doubting that.  But the aim here is to find a repeatable set of steps that will allow our developers to reproduce the issue on their machines.  We're not yet able to do that.

Since we've had 3 million or so downloads of AOO 3.4.1 on the Mac, and many of them will have used password-protected files, I'm assuming (but I may be wrong) that the simple, default case in a simple, default configuration, works correctly.  Otherwise we'd be seeing many more defect reports here.  

So the devil is in the details.  What are Juergen and I missing in our tests that you are doing?

Could it be that this works correctly in a new install, but not in an upgrade?

Could there be a dependency on a specific translation?  I'm testing with the en-US version of AOO 3.4.1.  Are you using a different translation?

Regards,

-Rob

I know you don't think I've fabricated images for a screenshot!  I am trying to say that I have seen the error on different machines, on different OS X versions, on an Admin account, and on a clean install. In fact, my September post notes that my clean install was on a wiped hard drive... doesn't get much cleaner. 

I don't know if it was 3.4.1 at the time.  

My recollection is that last fall I also reproduced the error on a Windows machine as well. 

I'll play around this week with different scenarios, and I'll see if there's any info that shows up in Console log. Any other ideas/suggestions for trouble shooting?

(In reply to comment #16)
@Ernie, please reply with information on the language of the install you use and also the language settings of your particular computer.  Also please identify the browsers installed on your machine.  (This is related to some security functions.)

Also, in Apache OpenOffice 3.4.x, see if you can find the registrymodifications.xcu document in your configuration information.  This is an XML document you can examine.  Or you can just upload it to this bug report and one of us will look it over.  On Windows the registrymodifications.xcu file is at the end of the user-specific path %APPDATA%\OpenOffice.org\3\user\ where %APPDATA% varies by operating system.  On XP SP3 it is
 C:\Documents and Settings\your-user-id\Application Data
On Windows Vista/7/8 it is C:\Users\your-user-id\AppData\Roaming

In this file, you want there to be two items with 
  ooor:path="/org.openoffice.Office.Common/Save/ODF"
one with prop "UseBlowfishInODF12" set to true and the other with prop "UseSHA1InODF12" set to true.

WHY THIS IS COMPLICATED (TL;DNR):

The password that is entered for saving and for opening a document is converted from UTF8 to an SHA1 hash.  That hash is then used to derive the key that is actually used to encrypt/decrypt the file.

There are two places where a deviation may occur.  If the UTF8 input method is different on two different configurations, the hashes will not agree.  This could be an operating system difference, it could be a difference in the open-office operation, or it could be a configuration difference.

There are also some default settings that govern *which* hash algorithm is used.  If there is a discrepancy between the hash algorithm used when the document was saved and where the attempt to open is happening, that will also fail.

Finally, if a document is damaged, you can get the "File cannot be opened" message saying the password is incorrect when that is not actually the problem.  This has to do with the fact that Apache OpenOffice doesn't know what the correct password is.  It uses the password that is entered, hashes it, etc., to then try decrypting the document.  It then checks to see if a decrypted part of the document has the same digital hash as the same part had when the document was encrypted.  (This is remembered as part of the metadata in the encrypted document.)  There can be a mismatch because of damage and/or because the hashing algorithm used to create the check value when the document was encrypted is different than the one using to check the decryption later.  

BOTTOM LINE: That is why so many details are needed from you.  Also, there were some changes in encryption parameters, but they should not impact documents saved with password in older versions.  The older versions use default cases, and it *might* be that some new configurations of Apache OpenOffice are not preserving the default cases properly.

Orcmid,

I'm running a Mac... there is no registry... let alone a C: drive.

(In reply to comment #18)
> Orcmid,
> 
> I'm running a Mac... there is no registry... let alone a C: drive.

There should still be a *file* named registrymodifications.xcu somewhere on your Mac.  If it has a different name, one of the developers who works with Mac can tell you about that, and also where to find it.  It is part of the user profile for your [Apache] OpenOffice installation and its configuration information.

I think we should chalk this up as a problem with the 3.4.0 install... at least, I'm convinced there was a bug there, but it is moot now.

I put 3.4.1 on a flash drive, and it ran fine on my 10.6, 10.7, and my other 10.8 machines.  This machine is the only one in which I installed 3.4.0 on this drive configuration (meaning, without subsequently wiping the drive.  I tried 3.4.0 on other machines last September with identical problems, but subsequently wiped them when I upgraded to OS X 10.8).

Tonight, after I removed the 3.4.0 app and deleted the '~\Library\Application Support\OpenOffice.org' folder, 3.4.1 ran successfully.

For what it is worth, I did look at the RegistryModification.xcu file.  Something didn't seem to match up with what you expected I would see.  There was only one instance of:

<item oor:path="/org.openoffice.Office.Common/Save/ODF">
  <prop oor:name="DefaultVersion" oor:op="fuse">
    <value>3</value>
  </prop>
</item>

Rob's original notice about duplicate Bug 121545 triggered me to look at this posting again.  Sorry for what may seem liked wasted effort, but I do appreciate it, since I'm now current with AOO.

I give up.  It hasn't even been a week, and now once again I can longer open a password saved file in 3.4 or save a file with a password in 3.4.... although 3.3 works fine.

I deleted the 'Application Support' files and still the same error.

(In reply to comment #3)
> Updated Component.  Was listed as website 'www', and should be product
> 'code'.

I think these end up under www because it is the only place there is a security category.  It is difficult for an user to know that it should be code instead.

(In reply to comment #17)
> (In reply to comment #16)
> @Ernie, please reply with information on the language of the install you use
> and also the language settings of your particular computer.  Also please
> identify the browsers installed on your machine.  (This is related to some
> security functions.)
Can you please provide this information?

Ernie, I gather from your later reports that Save with Password and subsequent opening of the saved file worked with Apache OpenOffice 3.4.1 for both saving and opening.  And then it stopped working with files saved and opened in 3.4.1 on the same machine?  Is that correct?  

We're trying to control the variables here so that there is something reproducible.  That's not possible unless you provide precise details, since no one else has reported the case and others have been unable to provoke it based on your information.

I'm sorry this is endlessly frustrating for you.  This is a bit like taking your car to the mechanic and their test drives can never provoke the strange noise and steering-column shudder that you experience.  

I am reopening this because it appears AOO 3.4.1 is not the fix.

(In reply to comment #22)
> (In reply to comment #3)
> > Updated Component.  Was listed as website 'www', and should be product
> > 'code'.
> 
> I think these end up under www because it is the only place there is a
> security category.  It is difficult for an user to know that it should be
> code instead.
Oops.  It was previously the only place.  I see that has changed or else I never found the correct place in the past, either.

I'm raising the importance of this because it involves data loss and that is always a serious matter.

-- OS language is English.
-- AOO 3.4.1 download file I used is Apache_OpenOffice_incubating_3.4.1_MacOS_x86_install_en-US
-- Installed browsers are Safari & Firefox

Running 3.4.1 alone did not fix the saving & opening of password protected files.  Deleting the ~/Library/Application Support/OpenOffice.org did seem to fix it... I know I opened and saved a few test files last week.

Today, I tried deleting the Application Support files again, but did not get it to work.  Curiously, I did get it to it to work today from an administrator account, although I tried that the other week, too, and it was not working previously.

(In reply to comment #25)
> I'm raising the importance of this because it involves data loss and that is
> always a serious matter.

There is no data loss here.  The user posted an example password-protected file that he could not open and I was able to open it fine.

(In reply to comment #27)

> There is no data loss here.  The user posted an example password-protected
> file that he could not open and I was able to open it fine.

Actually Rob, you posted the file, not me.  I only posted screen captures of the error messages.  I was always able to open both your test files and my own password protected files in 3.3.  

And yes, as long as I keep a copy of v3.3 around, there is no data loss.

This does not appear to be unique to me, however.
http://forum.openoffice.org/en/forum/viewtopic.php?f=6&t=55648
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=55698

(In reply to comment #28)
> (In reply to comment #27)
> 
> > There is no data loss here.  The user posted an example password-protected
> > file that he could not open and I was able to open it fine.
> 
> Actually Rob, you posted the file, not me.  I only posted screen captures of
> the error messages.  I was always able to open both your test files and my
> own password protected files in 3.3.  
> 
> And yes, as long as I keep a copy of v3.3 around, there is no data loss.
> 
> This does not appear to be unique to me, however.
> http://forum.openoffice.org/en/forum/viewtopic.php?f=6&t=55648
> http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=55698

Actually, this was a different user who sent me a password-protected file off-line and which I was able to open.  It was with this duplicate issue:

https://issues.apache.org/ooo/show_bug.cgi?id=121545

I'm happy to do the same for you, if you wish, to confirm this.

Regards,

-Rob

Although my administrator account continued to open the password protected file (stored on an external drive with permissions ignored), I could not do so from my account, even after making my account an administrator.

I deleted my account and recreated it, and thus far I am once again able to open password protected files.

I see that the Product was changed to Spreadsheet, but that this was not limited to Calc -- the problem was for all password protected files that I tried, including Rob's 3 files attached here.

(In reply to comment #30)

> I deleted my account and recreated it, and thus far I am once again able to
> open password protected files.

Another variation to try.  In Tools | Options | Load/Save | General change the ODF format version option to 1.0/1.1.  See if you are able to Save with Password and roundtrip back into your Apache OpenOffice 3.4.1 that way.  These should also open with 3.3.  If that also fails at some point, that will be useful for us to know.

Assuming Save with Password is simply for your own privacy and not sending encrypted files to others, this might help.  Experiment with it to ensure this still maintains the fidelity of the files that you work with.

AOO 3.4.1 worked initially on my new account, but has once again stopped working... and I can't think of any settings changes or software installs I've done that could have impacted it.

I used OO 3.3 to open the password protected .ODS and save it as a 1.0 format spreadsheet (.SXC) as well as Excel (.XLS) -- both with password protection.

Restarting AOO 3.4.1, I could not open the .ODS or the .SXC but the .XLS file opened.

Without a fix, I guess my choices are to use the file in .XLS format or to continue to use the OO 3.3 version.

we would really like to help you but we can't reproduce the problem. Maybe you can try to strip down the content of your document and can share the problematic document with us for further investigation. Make sure that the password is no longer secret and that you can share it with us.

(In reply to comment #33)
> we would really like to help you but we can't reproduce the problem. Maybe
> you can try to strip down the content of your document and can share the
> problematic document with us for further investigation. Make sure that the
> password is no longer secret and that you can share it with us.

I'm not sure how that matters, since it seems pretty clear that the document isn't the problem, for two reasons:

1)  If you'll look back, you'll see that Rob Weir posted three different kinds of password protected documents.  I could not open them in AOO 3.4.1, although I could with OO 3.3.

2) Additionally, as I have said, I am not able to create new documents and save them with a password with AOO 3.4.1. 

Incidentally, for completeness on my earlier post this morning about switching to MS Office format and being able to open password protected files, I am also able to create a new file in AOO 3.4.1 and save it in MS Office with a password.

Bump.

I've now checked the latest versions of OOo (4.0.1), LibreOffice (4.1.4.2), and NeoOffice (3.4.1). LibreOffice and NeoOffice open my password-protected .ods file just fine. OpenOffice says "The password is incorrect. The file cannot be opened."

So whatever the underlying mechanism is, the bug still exists in OOo.

As always, I use the file in question regularly, so I am happy to test any beta builds to verify whether or not this bug is fixed.

-H

Clarification: I'm on OS X (10.6.8). And of course by OOo I meant AOO.

(In reply to heywood from comment #35)
> I've now checked the latest versions of OOo (4.0.1), LibreOffice (4.1.4.2),
> and NeoOffice (3.4.1). LibreOffice and NeoOffice open my password-protected
> .ods file just fine. OpenOffice says "The password is incorrect. The file
> cannot be opened."

Heywood, that is not enough information to confirm that this is the same problem ernie was having.

Can you do the following:

 1. Open your password-protected file in LibreOffice or NeoOffice.  
 2. Delete any proprietary information.
 3. Save it with a new name and a *different* password, but including any special characters and spaces that you use in the current password (rearranged, of course).
 4. Verify that the file opens in LO and NeoO, and does not open in AOO 4.0.1 on your OS X configuration.

The idea is to be able to create a non-private saved-with password file that is accepted to the creating application but not AOO 4.0.1.

If you are able to do that, upload the file to this bug report and tell us what the password is so we can inspect the file to determine what the problem might be.

BONUS POINTS:
 Save a modified version (1-2 above) without any password.  Open it in AOO 4.0.1 and save that with the same password you used in (3).  Are all three apps able to open it when it is done that way?

(In reply to heywood from comment #35)
> I've now checked the latest versions of OOo (4.0.1), LibreOffice (4.1.4.2),
> and NeoOffice (3.4.1). LibreOffice and NeoOffice open my password-protected
> .ods file just fine. OpenOffice says "The password is incorrect. The file
> cannot be opened."

For me, this was a significant enough bug that I ultimately switched to LibreOffice.

Added hdu to CC