Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of tjfrazier@cfl.rr.com
 designates 75.180.132.120 as permitted sender)
Message-ID: <4F6CC04C.6060104@cfl.rr.com>
Date: Fri, 23 Mar 2012 14:26:20 -0400
From: TJ Frazier <tjfrazier@cfl.rr.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0;
 rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
 Down-Level
 Implementations
References: <4F672B1E.5050401@googlemail.com> <4F6731C1.30502@cfl.rr.com>
 <4F673912.8070504@googlemail.com> <4F6C54C1.8080100@a-w-f.de>
In-Reply-To: <4F6C54C1.8080100@a-w-f.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 3/23/2012 06:47, Andre Fischer wrote:
> Hi,
>
> there has been a longer discussion about this in the issue ([1]), most
> of it very technical. I previously thought that this is not a show
> stopper but I changed my mind but more for usability than technical
> reasons: I had expected that I could choose the encryption algorithm
> either in the save dialog or in the Tools->Options menu, but did not
> find a way to do it. Without this choice the user has two options:
>
> 1. Save as ODF 1.1
>
> 2. Not use encryption
>
>
> I don't find option 2 acceptable. Option 1 requires users to know that
> this solves their problem, i.e. that ODF 1.1 uses another encryption
> method than ODF 1.2. I did not know that before and assume that many
> others do not either.
>
> I see this now as a severe problem, even as a show stopper.
>
> Regards,
> Andre

+1

I agree that this should be a show stopper, so that the patch from 
Dennis (or something to accomplish the same effect, and retain the 
current Blowfish method as the default) should be integrated.

Given that, there are two more options to consider:

3. User change to config file, to use the new option.

I have suggested a writeup on this, but such instructions are much 
better aimed at the (few?) users who want the "latest and greatest" 
security option, and will do a little work to get it. (Does anybody know 
what that file name is? Given that, I volunteer to update the Release 
Notes.)

4. Macro to toggle the settings.

This could be distributed in a BASIC library (new or existing); no 
extension necessary. User instructions to find and run the macro are 
simple. I may be able to write this; preliminary investigation is 
promising but not certain. I volunteer to try. There are several real 
experts on this list, whom I might ask for help.

/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, J�rgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, J�rgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, J�rgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>