Hmmm... We did say we would not depend on Category B software for default behaviour so I am with Dennis on this one.
I also recall there are security issues with the two library versions of nss and xmlsec involved in this support. Pedro. --- Dom 25/3/12, Rob Weir <robw...@apache.org> ha scritto: ... > On Sat, Mar 24, 2012 at 4:50 PM, TJ > Frazier <tjfraz...@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.hamil...@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.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: > > > > > 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/ > > > > >
