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