SRU LibreOffice 3.5.4 for precise (was: Can't open/save document or spreadsheet with password, when mozilla profile has an absolute path)

Status changed to 'Confirmed' because the bug affects multiple users.

Yes. This bug showed up for me when I was unable to open previously saved password protected spreadsheets. Very panic inducing! That'll teach me to have 'proposed' active on a production machine...

Have the same problem when upgrade to Libreoffice 3.4.5.
Not only with Calc, have the same problem with Writer too.
Ubuntu 11.10 and Libreoffice 3.4.5 Spanish version

I also have the problem in both Calc & Writer. I cannot open documents saved with passwords under previous versions of LibreOffice, nor save new documents with passwords.
All passwords are confirmed correct & the old documents can be opened normally in OpenOffice 3.2.

Marcelo Terres, could you please post an example file, with password, that does not open in 3.4.5, but does in 3.4.4?

It is possible to open an existing password protected file (from 3.4.4) in 3.4.5. It works without problems.

The problem is that after I save it in 3.4.5 I can't open it anymore.

Attached is a test document that I saved with password="password" using the oneiric-updates (1:3.4.4-0ubuntu1) version of LibreOffice. Opening this document should fail under oneiric-proposed (1:3.4.5-0ubuntu1). See bug #919877 (https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/919877) for details.

The problem I encountered in #919877 is different from what Marcelo Terres described above in comment #6.

I found that a password-protected .odf document that I previously had saved under 3.4.4 could not be opened under 3.4.5. Downgrading to 3.4.4 allowed me to open the file again.

Also, I found that 3.4.5 LibreOffice Writer in oneiric-proposed failed to save a new document with password. It gave an error message instead.

Should the duplicate status between #919877 and #919659 be removed?

Marcelo Terres wrote:
 > It is possible to open an existing password protected file (from 3.4.4) in 3.4.5. It works without problems.
 > The problem is that after I save it in 3.4.5 I can't open it anymore.

Marking Triaged High as this Writer password protected files regression:
"Renders essential features or functionality of the application or dependencies broken or ineffective".

It's a UBUNTU bug only, not a LibreOffice bug.
Not reproducible with vanilla 3.4.5 version.
See https://bugs.freedesktop.org/show_bug.cgi?id=45171

Hello,

The title of this bug was just changed
from - "Can't save spreadsheet with password"
to + "Can't open spreadsheet with password"

... but I believe that's not correct.
  1. The problem is that BOTH opening AND saving fail with password.
  2. As described in duplicate bug #919877, the failures occur for BOTH LibreOffice Writer AND Calc.

For completeness, I recommend that the title be changed to:
  "Can't open or save document or spreadsheet with password"

OK?

Thanks,
--Jonathan

- I can not open calc files previously (before 3.4.5 update) saved with a password.
- I can not save a new document with a password. (I tried with Writer)

I also encountered the same problem of being unable to open a previously password protected spreadsheet or save a new password protected spreadsheet. But the problem went away after fully removing libreoffice, purging deb files, reinstalling libreoffice. I suspect that the problem appeared after I cloned my oneiric installation from a HDD to a SSD.

Guys, what does it means the status "Won't fix"? Means that purging libreoffice and reinstall the binary is the (only) solution?

Won't fix is from upstream. Their version, from which the Ubuntu version is derived, doesn't show the bug, so the upstream maintainers won't be fixing it themselves.

So far although rated high in importance the bug isn't assigned to anyone involved in Ubuntu to fix.

How you fix on your system I can't advise as I don't know whether you are running oneiric with the proposed repository active or pangolin...

However, for me I just open my encrypted documents on a machine running a pre-bug version for now.

For what it's worth, I've now upgraded to Precise Pangolin Beta 1.

This uses LibreOffice 3.5.0 Build 350m1(Build:13)

This bug does not now affect me. I can now save and open new and legacy password protected files as expected.

@mohican (jocelyn1b): Could you retry with a new user or after removing ~/.libreoffice and ~/.config/libreoffice?

Hi,
1. I uninstalled completely libreoffice, then reboot, then reinstall -> same bug
2. I removed ~/.config/libreoffice (there is no ~/.libreoffice on 12.04), then open new session -> same bug
3. I created a new normal user -> NO BUG !

mohican (jocelyn1b): Thanks for testing, thats very helpful. Can you try to remove (or move to backup) the ~/.mozilla folder for the user that is still affected? see https://bugs.freedesktop.org/show_bug.cgi?id=45171#c23 for details.

Yes, this solves the problem ! Thanks a lot !
Do you have more details so I know what to change in my firefox profile ?

I now tried my firefox profile with ALL extensions and plug-ins unactivated but this doesn't help : the bug is there again.

My firefox profile was on another disk partition than /home (because it is shared between several OS).
I have copied it into the ~/.mozilla folder and then there's no bug anymore !

So the bug it has nothing to do with the content of the firefox profile but it depends on the path to the firefox profile.

So when working with passwords, libreoffice does read the profile.ini file in ~/.mozilla folder (WHY?), then :
- if the path to the profile is not relative and situated outside the ~/.mozilla folder -> bug
- if the path is relative and inside the ~/.mozilla folder -> NO BUG

The problem seems that libreoffice doesn't like path that is not relative to the firefox folder.

When the firefox profile.ini is such :

[Profile1]
Name=user1
IsRelative=1
Path=user1
Default=1

it's OK for libreoffice

But when it is such :

[Profile1]
Name=user1
IsRelative=0
Path=/home/user1/.mozilla/firefox/user1
Default=1

libreoffice fails to open the password protected file !

libreoffice also fails if there is no ~/.mozilla folder at all.

(Firefox has no problem with the not relative path and, in this case, when launched with the second version of profile.ini it rewrites it into the first version (relative).
It cannot transform it when the path is outside of the firefox folder.)

Now the bug seems to be either that :
- libreoffice should not access the firefox profile when opening or saving password protected files ?
- and/or libreoffice cannot follow unrelative path in profile.ini

Remember : my config is not new, and it still works with libreoffice 3.4.4 on Ubuntu 11.10.
So it's some kind of a regression anyway. Affecting libreoffice 3.5.2.2

Marking back to Triaged as testcase is available.

Another user found out that in the libreoffice library
libmozabdrvlo.so
there are references to "profiles.ini" ".mozilla/firefox" "password" and also things related to Thunderbird.

As for Thunderbird : I have also a profile with absolute path. This is not buggy since I was able to open/save with password only by changing the profile path of Firefox.

Markus Mohrhard (see upstream bug) is currently investigating a fix for this. You can find his email in the upstream bug or as "moggi" on #libreoffice-dev on freenode IRC, if you want to help out directly. Thanks for everyone doing detective work on this one!

Fix commited upstream by Markus for 3.5.4:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf9ab0b486ee336bd4fb91e5ad2320d25593d696&g=libreoffice-3-5

I'm no expert, but here's my workaround
Going from ubuntu 10.04 to 12.04
Old file, made by OOO ver??, used by OOO ver?? and LO ver??, now LO writer v 3.5.2.2 now rejecting password.

Until now I have used the default placement for firefox, ie
/home/garry/.mozilla/firefox/profiles.ini
which said
IsRelative=0
Path=/media/data/mozilla/firefox/Profiles/ubuntu.default

Now I have
/home/garry/.mozilla/(symlink to /media/data/mozilla/firefox)/profiles.ini
which says
IsRelative=1
Path=ubuntu.default

So now password works.
(why on earth LO depends on Ff, who knows?)

Use the 3.5.4 from the libreoffice ppa, which has the fix. SRU is struck in ubuntu processes, so might take a while.

SRU boilerplate for 3.5.4 SRU:

== rationale ==
This is a release regression. Along with it 3.5.4 fixes a long list of bugs and regressions including some serious crashers with possible data loss:
* upstream bugfix release, fixes for rc1:
    - (Does not recognize VBA macro in JAPANESE...) fdo#49324 [Julien Nabet]
    - enable caching of grammar checker properties fdo#35270 [Michael Meeks]
    - special-case appending items to autocorrect lists fdo#46805 [Michael Meeks]
    - Changing spelling preferences requires application restart fdo#39999 [Szabolcs Dezsi]
    - add+use SwDoc::containsUpdatableFields fdo#49897 [Caolán McNamara]
    - allow keyword Append to be used as a variable. bnc#745930 [Noel Power]
    - allow zwj, etc. in metric unit text fdo#42390 [Caolán McNamara]
    - avoid recursion that can mess up DND setup fdo#41996 [Luboš Luňák]
    - clamp mnFillOpacity to 1 fdo#48065 [Chr. Rossmanith]
    - comparing empty document with attached one crashes LO fdo#43424 [Szabolcs Dezsi]
    - compound storage backend is poor at knowing stream size fdo#47644 [Caolán McNamara]
    - correctly map monitor index back to screen fdo#49365 [David Tardon]
    - count mirrored monitors as one rhbz#809019 [David Tardon]
    - crash on "connect to existing database" wizard fdo#45580 [Lionel Elie Mamane]
    - dmapper: fix import of titlepg top/bottom margin fdo#44176 [Miklos Vajna]
    - dmapper: handle m_bTitlePage when m_nBreakType is zero fdo#49940 [Miklos Vajna]
    - do not prepend \n twice, it confuses KFileDialog rhbz#820439 [Luboš Luňák]
    - drawinglayer: fix double hairline borders: fdo#48647 [Michael Stahl]
    - fix Presenter Console help screen layout fdo#46223 [Gábor Stefanik]
    - fix RTF export of empty paragraph numbering rules fdo#49692 [Miklos Vajna]
    - fix RTF export of non-breaking space/hyphen/optional hyphen fdo#38176 [Miklos Vajna]
    - fix RTF import of Russian characters without an encoding specified fdo#48023 [Miklos Vajna]
    - fix RTF import of \sl without \slmult fdo#48876 [Miklos Vajna]
    - fix RTF import of automatic paragraph background color fdo#47764 [Miklos Vajna]
    - fix RTF import of fields without a result fdo#48193 [Miklos Vajna]
    - fix RTF import of localized fields fdo#48037 [Miklos Vajna]
    - fix bean after gbuild'ification fdo#49580 [Stephan Bergmann]
    - fix incorrect square gradients in slideshow. fdo#49508 [Thorsten Behrens]
    - fix parsing of arc paths fdo#48070 [Chr. Rossmanith]
    - fix property type for printoptions fdo#45592 [Noel Power]
    - fix vertical text frame borders: fdo#44010 [Michael Stahl]
    - fixed crash while opening odt file. fdo#47436 [Dezsi Szabolcs]
    - implement RTF_CHPGN fdo#38786 [Miklos Vajna]
    - implement RTF_KEYWORDS fdo#49683 [Miklos Vajna]
    - merge consecutive border lines: fdo#38215 [Michael Stahl]
    - more robust nss initialization, related fdo#45171 [Markus Mohrhard] (LP: #919659)
    - overwrite incorrect font table entry with the correct one fdo#47347 [Caolán McNamara]
    - PPTX import crashes. fdo#48778 [Muthu Subramanian]
    - parse rgb(%,%,%) correctly fdo#47447 [Chr. Rossmanith]
    - performance problems with very long paragraph...

Hello Marcelo, or anyone else affected,

Accepted libreoffice into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Note that this has been accepted on the basis of the +1 to the micro release exception request in this thread:

https://lists.ubuntu.com/archives/technical-board/2012-June/001283.html

Once this is built, we need to see reports of at least smoke testing on all architectures.

verified, no known regressions.

Björn - what architectures have you tested this SRU on?

amd64, i386 are extensively tested (identical source package in the LibreOffice PPA since 2012-05-24. I havent tested ARM more than in build tests.

I've just done a clean install of Linux Mint Maya 64 bit. I dual boot this with Windows Vista Business 32 bit on my Dell D630. I like to keep the same environment, so in Linux, I have two profiles for Firefox: the default Linux, which I rarely use and the Windows which I select most of the time.

In the course of my investigations, I managed to lose my old Windows profile, so both are now new. I find that if I start up Firefox using the Windows profile, Libre Office has the encryption problems noted in this thread: i.e. won't save and says the password is incorrect on opening. If I open Firefox with the Linux profile then Libre Office works fine.

Seems very odd that a Firefox profile should affect a separate encryption programme, but clearly it does. I'm also very annoyed to have lost my Windows Firefox profile, but then I should have backed it up.

I forgot to mention that I updated L O by adding the 3.5.4 ppa to Synaptic. I now have 3.5.4.2 and that's still broken.

Hey John,

can you tell me what your profiles.ini contains? Normally 3.5.4 should fall back to initializing nss without mozilla if the with mozilla case fails. Normally the without mozilla case should succeed everywhere and should be able to open any encrypted files.

Sorry for the delay Markus, I wish I had more time to spend on interesting things ;-)

Here's ~/.mozilla/firefox/profiles.ini

[General]
StartWithLastProfile=0

[Profile0]
Name=default
IsRelative=1
Path=gsljspgu.default

[Profile1]
Name=Windows
IsRelative=0
Path=/media/Windows/Users/John/AppData/Roaming/Mozilla/Firefox/Profiles/q6kiiqff.default
Default=1

Marking this bug as verification-failed due to Bug #1021946 which seems to be related to libreoffice 3.5.4

Ok, so the submitter of bug #1021946 wrote

"yes, I tested it and thought I put the result but actually not... exactly the same thing happened to me in libreoffice 3.5.3. "

which means it's not a regression from the libreoffice update ... can we put that bug back to verification-done and get the SRU moving to updates?

According to the bug status here, this bug is not fixed in Quantal. But I see that Quantal has 3.6.0rc2.

Can somebody please verify that this is fixed in 3.6.0, and set the bug task status to 'Fix Released' if so? Once thats done 3.5.4 should be able to move forward to precise-updates.

This bug was fixed in the package libreoffice - 1:3.5.4-0ubuntu1

---------------
libreoffice (1:3.5.4-0ubuntu1) precise-proposed; urgency=low

  [ Bjoern Michaelsen ]
  * removed upstreamed lp-818761-Remove-SalDisplay-GetKeyboardName.diff
  * upstream bugfix release, fixes for rc1:
    - (Does not recognize VBA macro in JAPANESE...) fdo#49324 [Julien Nabet]
    - enable caching of grammar checker properties fdo#35270 [Michael Meeks]
    - special-case appending items to autocorrect lists fdo#46805 [Michael Meeks]
    - Changing spelling preferences requires application restart fdo#39999 [Szabolcs Dezsi]
    - add+use SwDoc::containsUpdatableFields fdo#49897 [Caolán McNamara]
    - allow keyword Append to be used as a variable. bnc#745930 [Noel Power]
    - allow zwj, etc. in metric unit text fdo#42390 [Caolán McNamara]
    - avoid recursion that can mess up DND setup fdo#41996 [Luboš Luňák]
    - clamp mnFillOpacity to 1 fdo#48065 [Chr. Rossmanith]
    - comparing empty document with attached one crashes LO fdo#43424 [Szabolcs Dezsi]
    - compound storage backend is poor at knowing stream size fdo#47644 [Caolán McNamara]
    - correctly map monitor index back to screen fdo#49365 [David Tardon]
    - count mirrored monitors as one rhbz#809019 [David Tardon]
    - crash on "connect to existing database" wizard fdo#45580 [Lionel Elie Mamane]
    - dmapper: fix import of titlepg top/bottom margin fdo#44176 [Miklos Vajna]
    - dmapper: handle m_bTitlePage when m_nBreakType is zero fdo#49940 [Miklos Vajna]
    - do not prepend \n twice, it confuses KFileDialog rhbz#820439 [Luboš Luňák]
    - drawinglayer: fix double hairline borders: fdo#48647 [Michael Stahl]
    - fix Presenter Console help screen layout fdo#46223 [Gábor Stefanik]
    - fix RTF export of empty paragraph numbering rules fdo#49692 [Miklos Vajna]
    - fix RTF export of non-breaking space/hyphen/optional hyphen fdo#38176 [Miklos Vajna]
    - fix RTF import of Russian characters without an encoding specified fdo#48023 [Miklos Vajna]
    - fix RTF import of \sl without \slmult fdo#48876 [Miklos Vajna]
    - fix RTF import of automatic paragraph background color fdo#47764 [Miklos Vajna]
    - fix RTF import of fields without a result fdo#48193 [Miklos Vajna]
    - fix RTF import of localized fields fdo#48037 [Miklos Vajna]
    - fix bean after gbuild'ification fdo#49580 [Stephan Bergmann]
    - fix incorrect square gradients in slideshow. fdo#49508 [Thorsten Behrens]
    - fix parsing of arc paths fdo#48070 [Chr. Rossmanith]
    - fix property type for printoptions fdo#45592 [Noel Power]
    - fix vertical text frame borders: fdo#44010 [Michael Stahl]
    - fixed crash while opening odt file. fdo#47436 [Dezsi Szabolcs]
    - implement RTF_CHPGN fdo#38786 [Miklos Vajna]
    - implement RTF_KEYWORDS fdo#49683 [Miklos Vajna]
    - merge consecutive border lines: fdo#38215 [Michael Stahl]
    - more robust nss initialization, related fdo#45171 [Markus Mohrhard] (LP: #919659)
    - overwrite incorrect font table entry with the correct one fdo#47347 [Caolán McNamara]
    - PPTX import crashes. fdo#48778 [Muthu Subramanian]
    - parse rgb(%,%,%) correctly fdo#47447 [Chr. Rossmanith]
    - ...