On Sun, Mar 25, 2012 at 6:22 PM, Pedro Giffuni <[email protected]> wrote:
> Hmmm... > > We did say we would not depend on Category B software > for default behaviour so I am with Dennis on this one. > > OK. Fine. Let's just preserve the ability for user to set AES option via the configuration setting. (We can add a UI for this in 4.0). Users who are smart enough to know they want AES will be smart enough to set that option. I also recall there are security issues with the two > library versions of nss and xmlsec involved in this > support. > > All software has bugs. Software that is tested has reported bugs. Do we not have bug reports concerning our default encryption because the code is error free? Or....? -Rob > Pedro. > > --- Dom 25/3/12, Rob Weir <[email protected]> ha scritto: > ... > > 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/ > > > > > > > > >
