incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TJ Frazier <tjfraz...@cfl.rr.com>
Subject Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Date Sat, 24 Mar 2012 20:50:01 GMT
On 3/24/2012 12:22, Rob Weir wrote:
> On Sat, Mar 24, 2012 at 9:45 AM, Dennis E. Hamilton
> <dennis.hamilton@acm.org>  wrote:
>> Correcting my own typos and over-abbreviation of the previous post ...
>>
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
>> Sent: Saturday, March 24, 2012 06:28
>> To: ooo-dev@incubator.apache.org
>> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
>>
>> Rob,
>>
>>   1. It is absurd to make headway to strengthen security without addressing the weakest
links first. When has that ever been a design principle?
>>
>
> It is not absurd at all.  When I leave my house I lock the back door
> before the front, even thought I know the back door would be easier to
> break through.  There is no mandated order in which we do things.
> But you seem to be arguing for leaving the back door open just because
> you think the front door's lock is weak.  That is absurd.
>
> So -1 from me to changing the default unless you can come up with a
> far better technical argument than you have.  For example, you might
> demonstrate that users are actually confused by this change.  It would
> be good to show some evidence of this.  Since OOo 3.4 beta had this
> same change, and LibreOffice has made it as well, there should be 10
> million+ users with the AES encryption enabled by default.  Can you
> point us to something in the support forum or user lists where such
> complaints/confusion are reported?   If it is a real problem we surely
> would be hearing this from users.
>
> -Rob
>
-1 for the arguments, and the release as it is, because:

(1) The new encryption setting is *not* a user-changeable default. There 
is no current way to change it at the user level; where it is in effect, 
they're stuck with it.
(2) IIRC, the adoption by LO is very recent. Do /they/ have a GUI 
option? If not, bad on them, too.
(3) OO.o 3.4 Beta is trumpeted as experimental, not for production. We 
have no idea how many users may have tried to read a 3.4 encrypted file 
with 3.3, failed, and snorted, "Hmpf! /That/ doesn't work! Well, no need 
for me to write a bug report on it; it's so obvious, they're sure to 
catch it."
(4) What's the almighty great push to do this wrong? The fix seems 
simple and isolated, the testing is certainly simple: nothing to delay 
the release. It is *wrong* to break compatibilities as this does, 
without long lead-time, and opt-in possibilities, unless there exists 
some drastic need. That has not been shown. Improvement, yes; crucial, 
no. (Taking into account the recent history of occult exploits, in such 
a case I would offer the same course of action, with one addition: "We 
SHALL offer an opt-in UI method.")
(5) I have offered to help with a temporary UI, via macro or extension. 
I would much rather get back to that work, rather than argue further. 
"Which is more important?" is not a rhetorical question.

/tj/


Mime
View raw message