RE: Recovering from broken password (bug 125431)

[Dennis E. Hamilton]

Here's my understanding of *some*cases* of this problem based on what we now 
know about the cases that are reported and a patch that is being tested:

The user profile has nothing to do with this problem, and reinstalling AOO 
4.1.2 will not help either.

The problem is with a dependency on the platform.  Going back to an older 
version of AOO should not work either, because the change is not in AOO but in 
the updated OS configuration.  It takes an update to AOO to adjust for the 
changed dependency.  (It is not clear whether there is a manual workaround that 
can be used in the meantime.)

The only immediate solution, pending an updated AOO release, is to take the 
file to an older OS or one that does not have the problem (e.g, on Windows) 
long enough to decrypt the file.  Alternatively, the user could install the 
latest release of LibreOffice to see if that overcomes this problem.

This does not apply to problems of lost or incorrect passwords.  When the 
password is lost, there is generally no way to decrypt the file on any 
configuration of OpenOffice.  There are some utilities that can discover the 
password if it is not very secure against being guessed.  The better the 
password's random structure and length, the less likely there is a way to 
decrypt the file.

There is some technical discussion here on the dev@ list, involving the 
dependency on NSS.

 - Dennis


> -Original Message-
> From: Rory O'Farrell [mailto:ofarr...@iol.ie]
> Sent: Friday, January 22, 2016 10:19
> To: dev@openoffice.apache.org
> Cc: F C. Costero 
> Subject: Re: Recovering from broken password (bug 125431)
> 
> On Fri, 22 Jan 2016 11:03:48 -0700
> "F C. Costero"  wrote:
> 
> > We get questions on the forum about how to access a document that no
> longer
> > accepts the encryption password. I assume some of these are due to the
> > broken NSS issue #125431. I skimmed through the comments on bugzilla
> and
> > did not see a definitive way to fix the problem. I"m sorry if I missed
> it.
> > What should we tell users to do if we conclude they have this problem?
> > Thank you!
> > Francis
> 
> I saw this query on the Forum and was going to reply to suggest deleting
> or renaming the user profile; If that doesn't work it is worth trying on
> another Mac system, to see if the problem is o.s. specific and also on
> another o.s. It may be a report disguising some form of the corrupt file
> problem.  Also worth asking of the affected system can save a new trial
> passworded file and properly reopen it, to define whether the problem is
> specific to that file, or specific to that system.
> 
> Rory
> 
> 
> 
> --
> Rory O'Farrell 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Carl Marcum]

On 01/22/2016 12:04 PM, Marcus wrote:

Am 01/22/2016 01:22 PM, schrieb Jan Høydahl:
Probably not very future proof, since it will soon get outdated as 
Java moves on to new versions.


+1
Please do not choose a Java platform that is getting out-of-date. This 
is not helpful when it comes to bugs that will no longer be fixed.


Marcus



I understand.

My thought was that it would only be used as a fall back in case the 
user had no JDK on their system so we don't have to ship the office with 
reduced functionality.


I wasn't sure if it would be feasible.

Carl


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Recovering from broken password (bug 125431)

[Rory O'Farrell]

On Fri, 22 Jan 2016 11:03:48 -0700
"F C. Costero"  wrote:

> We get questions on the forum about how to access a document that no longer
> accepts the encryption password. I assume some of these are due to the
> broken NSS issue #125431. I skimmed through the comments on bugzilla and
> did not see a definitive way to fix the problem. I"m sorry if I missed it.
> What should we tell users to do if we conclude they have this problem?
> Thank you!
> Francis

I saw this query on the Forum and was going to reply to suggest deleting or 
renaming the user profile; If that doesn't work it is worth trying on another 
Mac system, to see if the problem is o.s. specific and also on another o.s. It 
may be a report disguising some form of the corrupt file problem.  Also worth 
asking of the affected system can save a new trial passworded file and properly 
reopen it, to define whether the problem is specific to that file, or specific 
to that system.

Rory



-- 
Rory O'Farrell 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Recovering from broken password (bug 125431)

[F C. Costero]

We get questions on the forum about how to access a document that no longer
accepts the encryption password. I assume some of these are due to the
broken NSS issue #125431. I skimmed through the comments on bugzilla and
did not see a definitive way to fix the problem. I"m sorry if I missed it.
What should we tell users to do if we conclude they have this problem?
Thank you!
Francis

Including Java

[Carl Marcum]

Did anyone test AOO using Apache Harmony as the JRE?

I was wondering if it would have enough functionality to bundle as the 
default and then set the JRE to point at a users install if found.


I know Harmony is in the Attic now but I read somewhere it was 99% 
function but not necessarily compatible.


Just a thought.

Best regards,
Carl


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Marcus]

Am 01/22/2016 10:10 PM, schrieb Carl Marcum:

On 01/22/2016 12:04 PM, Marcus wrote:

Am 01/22/2016 01:22 PM, schrieb Jan Høydahl:

Probably not very future proof, since it will soon get outdated as
Java moves on to new versions.


+1
Please do not choose a Java platform that is getting out-of-date. This
is not helpful when it comes to bugs that will no longer be fixed.

Marcus



I understand.

My thought was that it would only be used as a fall back in case the
user had no JDK on their system so we don't have to ship the office with
reduced functionality.

I wasn't sure if it would be feasible.


sure, a bundled JRE as fallback solution would be very comfortable for 
the user and to some degree I share your idea. But it has also some 
disadvantages:


- Who is responsible for updating it when it's outdated (and the usual 
JRE needs to be updated several times per year ;-) )? The user who has 
installed it or AOO because it was bundled?


- Bundled software will increase the size of every download file 
(currently Oracle's JRE "costs" ~40-60 MB [1]) - and AOO has already a 
size that needs to be reduced better sooner than later.


- We have to keep the bundled JRE always up-to-date in the build process 
which is some effort. At Sun/Oracle times this was done and the bundled 
JRE was really often outdated and we had to update this with every new 
OpenOffice release. I remember that we had to re-build everything too 
often because it just was forgotten to update it.


As fallback solution a message box with text like "a suitable JRE wasn't 
found, but needed for the functions a,b,c and therefore it should be 
installed from xyz" is IMHO better.


But - as always ;-) - this is just my 2ct.

[1] 
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Jan Høydahl]

Probably not very future proof, since it will soon get outdated as Java moves 
on to new versions.
I agree it is sad we don’t have a permissive-licensed version of the JRE 
anymore :(

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 22. jan. 2016 kl. 12.00 skrev Carl Marcum :
> 
> Did anyone test AOO using Apache Harmony as the JRE?
> 
> I was wondering if it would have enough functionality to bundle as the 
> default and then set the JRE to point at a users install if found.
> 
> I know Harmony is in the Attic now but I read somewhere it was 99% function 
> but not necessarily compatible.
> 
> Just a thought.
> 
> Best regards,
> Carl
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Marcus]

Am 01/22/2016 01:22 PM, schrieb Jan Høydahl:

Probably not very future proof, since it will soon get outdated as Java moves 
on to new versions.


+1
Please do not choose a Java platform that is getting out-of-date. This 
is not helpful when it comes to bugs that will no longer be fixed.


Marcus




22. jan. 2016 kl. 12.00 skrev Carl Marcum:

Did anyone test AOO using Apache Harmony as the JRE?

I was wondering if it would have enough functionality to bundle as the default 
and then set the JRE to point at a users install if found.

I know Harmony is in the Attic now but I read somewhere it was 99% function but 
not necessarily compatible.

Just a thought.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Rony G. Flatscher (Apache)]

On 22.01.2016 13:22, Jan Høydahl wrote:
> Probably not very future proof, since it will soon get outdated as Java moves 
> on to new versions.
Harmony was planned to be at level 1.5/5, Google has been using it for Android, 
cf.
.

As long as new versions of Java still run "backlevel" Java 1.5/5 compiled code 
(the Java classfile
format of Java 1.5/5) Harmony programs would keep running. So as long as AOO 
Java programs get
compiled against Harmony this might be an option.

---rony



>> 22. jan. 2016 kl. 12.00 skrev Carl Marcum :
>>
>> Did anyone test AOO using Apache Harmony as the JRE?
>>
>> I was wondering if it would have enough functionality to bundle as the 
>> default and then set the JRE to point at a users install if found.
>>
>> I know Harmony is in the Attic now but I read somewhere it was 99% function 
>> but not necessarily compatible.
>>
>> Just a thought.
>>
>> Best regards,
>> Carl
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Including Java

[Damjan Jovanovic]

On Fri, Jan 22, 2016 at 2:22 PM, Jan Høydahl  wrote:

> Probably not very future proof, since it will soon get outdated as Java
> moves on to new versions.
> I agree it is sad we don’t have a permissive-licensed version of the JRE
> anymore :(
>
>
We kind of do, see
https://en.wikipedia.org/wiki/Comparison_of_Java_virtual_machines

The following are permissively licensed JVMs:
Avian under the ISC license (promising)
IKVM.NET under the zlib license (just uses the underlying .NET environment)
VMKit J3 from the LLVM project, under the University of Illinois/NCSA Open
Source License (unmaintained)

Class library wise, OpenJDK's one and GNU Classpath's one are both GPL with
classpath exception. Harmony was Apache licensed. Avian has its own
miniature class library even more permissively licensed, but it's nowhere
near developed enough for most real world Java usage (
https://github.com/ReadyTalk/avian/tree/master/classpath/java).

Android recently switched to OpenJDK, but its previous class library was
probably the most advanced fork of Harmony's class library in existence.
Avian can use both OpenJDK and the old Android class library, and can JIT
at runtime or AOT Java code into a standalone executable (
http://readytalk.github.io/avian/).

Damjan


> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 22. jan. 2016 kl. 12.00 skrev Carl Marcum :
> >
> > Did anyone test AOO using Apache Harmony as the JRE?
> >
> > I was wondering if it would have enough functionality to bundle as the
> default and then set the JRE to point at a users install if found.
> >
> > I know Harmony is in the Attic now but I read somewhere it was 99%
> function but not necessarily compatible.
> >
> > Just a thought.
> >
> > Best regards,
> > Carl
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Remove NSS from xmlsecurity - alternatives?

[Kay Schenk]

On 01/21/2016 04:27 PM, Damjan Jovanovic wrote:
> On Thu, Jan 21, 2016 at 11:53 PM, Kay Schenk  wrote:
> 
>>
>>
>> On 01/21/2016 10:04 AM, Damjan Jovanovic wrote:
>>> On Thu, Jan 21, 2016 at 7:29 PM, Kay Schenk 
>> wrote:
>>>


 On 01/16/2016 05:25 AM, Damjan Jovanovic wrote:
> On Sat, Jan 16, 2016 at 12:16 AM, Kay Schenk 
 wrote:
>
>>
>> On 01/15/2016 12:18 AM, Damjan Jovanovic wrote:
>>> Hi
>>>
>>> I believe we now have enough evidence that a serious issue, #125431,
>> where
>>> AOO lies that the password for encrypted files is wrong when it
>> isn't,
 is
>>> caused by a failure in NSS:
>>> * deliberately corrupting the Mozilla profile reproduces the issue on
 all
>>> operating systems
>>> * a patch I've written that reimplements xmlsecurity digest functions
>> using
>>> OpenSSL instead of NSS, allows encrypted documents to open despite a
>>> corrupted Mozilla profile
>>> * someone with the issue on FreeBSD reported my patch fixes it
>>>
>>> Always having been category B and now also commonly breaking in the
>> field,
>>> it's past time for NSS to go. But this brings me to my question: what
 do
>> we
>>> replace it with?
>>>
>>> We already use OpenSSL for some things, and my patch which uses it is
>>> enough to fix the problem with opening encrypted files. Its license
 suits
>>> us better. Our libxmlsec library can use it in place of NSS.
>>
>> Thank you for your work on this. I am certainly in favor of just
>> using OpenSSL assuming it won't cause backward compatibly issues.
>>
>>>
>>> Java has a rich cryptographic API and is widely used for
>> cryptography.
 It
>>> is however an optional dependency to AOO. It also needs the unlimited
>>> strength JCE policy files to use AES-256, but there are workarounds.
>>>
>>> Are there more?
>>>
>>> The important differences are:
>>> * NSS has passed FIPS-140 validation (
>>> https://wiki.mozilla.org/FIPS_Validation). OpenSSL hasn't really (
>>> https://www.openssl.org/docs/fipsnotes.html) while Java supposedly
 has (
>>>
>>

>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/FIPS.html
>> ).
>>> Do we care?
>>> * We use certificate verification (for what, digitally signed
>> documents?).
>>> This means we need access to the root certificates of all the CAs.
>> Securely
>>> updating, expiring and revoking CA certificates across 40 million
>> users
>> is
>>> a problem we should rather delegate to someone else. Currently, we
>> are
>>> using MSCrypto on Windows, and Thunderbird's/Firefox's certificates
 (via
>>> NSS) on other platforms. OpenSSL doesn't come with a list of CA
>>> certificates. Java does, but I don't know whether "This file is
>> encrypted,
>>> please install Java to open it" will fly.
>>>
>>> Maybe we could combine them. Use OpenSSL for most of xmlsecurity, and
>> fall
>>> back to Java when available for its certificates? Or keep NSS but
>> scale
>> it
>>> down to only dealing with certificates, and use something else for
>>> implementing other xmlsecurity features?
>>>
>>> Thank you
>>> Damjan
>>>
>>
>
> I came to the conclusion NSS was probably chosen for FIPS-140
>> compliance,
> the root CA certificates, and the UI in Thunderbird/Firefox for
 configuring
> digital certificates system-wide on many platforms, and since it does a
 lot
> and no other crypto library really has all those features, it's best to
> debug and fix our NSS usage for now and consider the other options
>> later.
> Which I did in r1724971:
>
> #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.
>
> Now let's release that to our users in 4.2.0