[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#659720: Bug#659733: libreoffice: -writer and -calc cannot open/save files with passwords



found 659733 1:3.4.5-2
found 659733 1:3.5.0~rc3-1
forwarded 659733 https://bugs.freedesktop.org/show_bug.cgi?id=45171
forcemerge 659733 659720
thanks

Hi,

On Mon, Feb 13, 2012 at 02:41:11PM +0100, Noel Köthe wrote:
> Package: libreoffice
> Version: 1:3.4.5-2 1:3.5.0~rc3-1

Look slike the BTS cannot handle that properly.

> Dear Maintainer,
> 
>    * What led up to the situation?
> 
> I want to open a few weeks old password protected file created with
> libreoffice but get the error dialog "The password is incorrect. The file
> cannot be opened."
> 
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
> 
> open file and entered password
> 
>    * What was the outcome of this action?
> 
> error message
> 
>    * What outcome did you expect instead?
> 
> decrypt and open the file.
> 
> I tested it many time witht he correct password. The I created a new file and
> wanted to save the new file (local) with a password (e.g. test) and get the
> error dialog "Error saving the document test: General error. general input/output error."
> So I cannot open and create a file with a password.
> Then I tested the version in experimental (1:3.5.0~rc3-1) with the same result
> that you cannot open and save a password protected file anymore.
> 
> Tested it on a Debian machine of a co-worker and is reproducable there.
> 
> Simple testcase:
> - start lowriter
> - "save as"
> - choose "with password"
> - enter a password two times
> - OK/Save
> - you will get an error
> 
> I cannot open and save password protected libreoffice files anymore.
> 
> Can you reproduce this?

Sounds like #659720.

Now that it doesn't happen even with 3.5.0 rc3 where we do not patch anything
code-wise makes me think that something in system-libraries (nss?) changed...

It does not help that  upstream builds with an old internal nss version.
(nss-3.12.8--with-nspr-4.8.6 vs. our
$ rmadison -s sid libnss3-1d libnspr4-0d
 libnspr4-0d | 4.9~beta5-2                | sid | amd64, armel, armhf, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 libnss3-1d  | 3.13.1.with.ckbi.1.88-1    | sid | amd64, armel, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
 libnss3-1d  | 3.13.1.with.ckbi.1.88-1+b1 | sid | armhf
)

Will try with internal nss, but *no* I am *not* going to use internal nss,
however bad this bug is....

Regards,

Rene



Reply to: