Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: TJ Frazier <tjfrazier <at> cfl.rr.com>
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Newsgroups: gmane.comp.apache.incubator.ooo.devel
Date: Saturday 24th March 2012 20:50:01 UTC (over 6 years ago)
On 3/24/2012 12:22, Rob Weir wrote:
> On Sat, Mar 24, 2012 at 9:45 AM, Dennis E. Hamilton
>   wrote:
>> Correcting my own typos and over-abbreviation of the previous post ...
>>
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:[email protected]]
>> Sent: Saturday, March 24, 2012 06:28
>> To: [email protected]
>> 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/
 
CD: 19ms