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 23:47:56 GMT
On Sun, Mar 25, 2012 at 6:22 PM, Pedro Giffuni <pfg@apache.org> 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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message