incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Date Sun, 25 Mar 2012 19:59:25 GMT
On Sat, Mar 24, 2012 at 4:50 PM, TJ Frazier <tjfrazier@cfl.rr.com> wrote:

> 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<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:
>
>
It does not meet the criteria we agreed on for a release blocking issue:
http://wiki.services.openoffice.org/wiki/Stopper

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.

-Rob


> (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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message