On 3/24/2012 12:22, Rob Weir wrote:
On Sat, Mar 24, 2012 at 9:45 AM, Dennis E. Hamilton
<dennis.hamil...@acm.org> wrote:
Correcting my own typos and over-abbreviation of the previous post ...
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamil...@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/
