incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Date Sun, 25 Mar 2012 22:22:08 GMT
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 <robweir@apache.org> ha scritto:
...
> 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
View raw message