Features Download

From: Rob Weir <robweir <at> apache.org>
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Newsgroups: gmane.comp.apache.incubator.ooo.devel
Date: Sunday 25th March 2012 19:59:25 UTC (over 6 years ago)
On Sat, Mar 24, 2012 at 4:50 PM, TJ Frazier  wrote:

> 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]**org
>>> ]
>>> 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:
It does not meet the criteria we agreed on for a release blocking issue:

Now, we can either maintain some discipline in how we triage remaining
bugs, and get out a release in a finite amount of time.  Or we can
degenerate into 90 individual PPMC member/politicians, and give ultimatums
and threaten to vote -1 unless our personal preferences are prioritized
above everyone else's.

Remember, the encryption has been set to AES since 3.4 Beta, 9 months ago.
I have not seen any user complaints.  LO has made the same choice.  I have
not seen any user complaints there either.  And now we're going to hold up
the release for this?  Really?

Again, -1 to changes to are not fixing show stopping issues.


> (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
> 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
> lead-time, and opt-in possibilities, unless there exists some drastic
> That has not been shown. Improvement, yes; crucial, no. (Taking into
> account the recent history of occult exploits, in such a case I would
> the same course of action, with one addition: "We SHALL offer an opt-in
> 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.
> is more important?" is not a rhetorical question.
> /tj/
CD: 14ms