You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@googlemail.com> on 2012/03/19 13:48:30 UTC
[RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Hi,
I think issue 119090 is no show stopper from my point of view. The new
default provides a better security than before when I understand it
correct. And if people detect potential problems they can save the
document again with other settings.
I agree that this is important for interoperability but no show stopper.
Any other opinion?
Juergen
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
Down-Level Implementations
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 25, 2012 at 6:22 PM, Pedro Giffuni <pf...@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 <ro...@apache.org> ha scritto:
> ...
> > On Sat, Mar 24, 2012 at 4:50 PM, TJ
> > Frazier <tj...@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
> > >> <de...@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<de...@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/
> > >
> > >
> >
>
RE: [OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I didn't mean Apache OpenOffice. When I mean that I use AOO or something similar.
I suppose it would be good to have said
"I have seen user complaints about the encryption problem on OpenOffice.org and/or LibreOffice lists."
- Dennis
-----Original Message-----
From: eric b [mailto:eric.bachard@free.fr]
Sent: Sunday, March 25, 2012 22:20
To: ooo-dev@incubator.apache.org
Subject: Re: [OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Le 26 mars 12 à 07:10, Dennis E. Hamilton a écrit :
> I use OOo/LO when I am talking about *both* of them. What would
> you suggest?
>
On my side I try to always write the full name : Apache OpenOffice
and / or LibreOffice, more accurate and always precise.
My 2 cts
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: [OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by eric b <er...@free.fr>.
Le 26 mars 12 à 07:10, Dennis E. Hamilton a écrit :
> I use OOo/LO when I am talking about *both* of them. What would
> you suggest?
>
On my side I try to always write the full name : Apache OpenOffice
and / or LibreOffice, more accurate and always precise.
My 2 cts
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
RE: [OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I use OOo/LO when I am talking about *both* of them. What would you suggest?
- Dennis
-----Original Message-----
From: eric b [mailto:eric.bachard@free.fr]
Sent: Sunday, March 25, 2012 20:13
To: ooo-dev@incubator.apache.org
Subject: [OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Hi Dennis,
Le 25 mars 12 à 22:11, Dennis E. Hamilton a écrit :
> I have seen user complaints about the encryption problem on OOo/LO
> lists. I haven't been keeping track of them, though.
>
Is it possible to stop using OOo in "OOo/LO please" ?
concatenate OOo with LO in the name leads to confusion, and enforce
the idea LO is OOo, what is basicaly wrong marketing (but sadly
exaxtly what some people do ..)
Thanks in advance;
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
[OT] Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by eric b <er...@free.fr>.
Hi Dennis,
Le 25 mars 12 à 22:11, Dennis E. Hamilton a écrit :
> I have seen user complaints about the encryption problem on OOo/LO
> lists. I haven't been keeping track of them, though.
>
Is it possible to stop using OOo in "OOo/LO please" ?
concatenate OOo with LO in the name leads to confusion, and enforce
the idea LO is OOo, what is basicaly wrong marketing (but sadly
exaxtly what some people do ..)
Thanks in advance;
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I have seen user complaints about the encryption problem on OOo/LO lists. I haven't been keeping track of them, though.
Evidently, the LibreOffice team considers this problem to have been solved by back-porting the consumption of AES256 to LibreOffice 3.4 with the LO 3.4.5 (January) and 3.4.6 (just-now) releases. I haven't checked to see if that changes the "Save with Password" behavior in those LO 3.4 versions or it simply provides consumption of the AES256 default output from up-level LO 3.5.x versions.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Sunday, March 25, 2012 12:59
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
[ ... ]
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
[ ... ]
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by Pedro Giffuni <pf...@apache.org>.
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 <ro...@apache.org> ha scritto:
...
> On Sat, Mar 24, 2012 at 4:50 PM, TJ
> Frazier <tj...@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
> >> <de...@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<de...@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/
> >
> >
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
Down-Level Implementations
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 24, 2012 at 4:50 PM, TJ Frazier <tj...@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
>> <de...@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<de...@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/
>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 3/24/2012 12:22, Rob Weir wrote:
> On Sat, Mar 24, 2012 at 9:45 AM, Dennis E. Hamilton
> <de...@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]
>> 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:
(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/
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
Down-Level Implementations
Posted by Rob Weir <ro...@apache.org>.
On Sat, Mar 24, 2012 at 9:45 AM, Dennis E. Hamilton
<de...@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]
> 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
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Correcting my own typos and over-abbreviation of the previous post ...
-----Original Message-----
From: Dennis E. Hamilton [mailto: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?
2. The proposal is not to abandon AES but to not make it the default. Folks for whom AES is imperative can elect it. Packagers in enterprises can even configure it. If it is as easy as claimed, why *not* do this *rather than impose a* silent, forced change that causes the most pain to the least-expert?
3. To address a check-off item without addressing the actual security situation and what is achieved in actual context brands us as the amateurs. For me, it is an ethical issue I can't step over as a computer-system professional. (The fact that I can see this much as an amateur document-security wonk is an indication of how fragile, and amateurish, the security of ODF document encryption is.)
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, March 23, 2012 17:32
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
On Fri, Mar 23, 2012 at 4:23 PM, Dennis E. Hamilton
[ ... ]
Yes, security is only as strong as the weakest link. But that is an
argument for improving all the links. It is not an argument for
undoing improvements that have already been made to some of the links.
We're not required to refurbish the battleship all in one day. We
can work deck-by-deck.
The advantage of AES is that it is a known quantity, a standard, and
is called out as a requirement for government procurement in several
countries, including the US.
[*Restored:*] We're not called on to individually become amateur cryptographers on
this project. That would benefit absolutely no one. Instead we
should follow existing industry standards and best practices, one of
which is AES. And if there are other parts of the encryption pipeline
that can be improved, then let's do that as well.
[ ... ]
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
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?
2. The proposal is not to abandon AES but to not make it the default. Folks for whom AES is imperative can elect it. Packagers in enterprises can even configure it. If it is as easy as claimed, why do this instead of a silent, forced change that causes the most pain to the least-expert?
3. To address a check-off item without addressing the actual security situation and what is achieved in actual context brands us as the amateurs. For me, it is an ethical issue I can't step over as a computer-system professional. (The fact that I can see this much as an amateur document-security wonk is an indication of how fragile, and amateurish, the security of ODF document encryption is.)
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, March 23, 2012 17:32
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
On Fri, Mar 23, 2012 at 4:23 PM, Dennis E. Hamilton
[ ... ]
Yes, security is only as strong as the weakest link. But that is an
argument for improving all the links. It is not an argument for
undoing improvements that have already been made to some of the links.
We're not required to refurbish the battleship all in one day. We
can work deck-by-deck.
The advantage of AES is that it is a known quantity, a standard, and
is called out as a requirement for government procurement in several
countries, including the US.
[ ... ]
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
Down-Level Implementations
Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 23, 2012 at 4:23 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
<snip>
<snip>
<snip>
<snip>
<snip>
> THE DEBATE: There is extensive technical discussion on the Bugzilla comments. Here is a summary of what all of that technicality is about:
>
> 1. Some presume that switching to AES256 increases the security of the document.
>
> 2. The counter-argument is that it does no good to improve the security in parts of the encryption that do not improve the security of the weakest-link in the encryption technique. It will simply give a false sense of security where there is no improvement. The weak link in ODF 1.0/1.1/1.2 encryption is the way that passwords are used. Not in the encryption technique that is used for the document.
>
Yes, security is only as strong as the weakest link. But that is an
argument for improving all the links. It is not an argument for
undoing improvements that have already been made to some of the links.
We're not required to refurbish the battleship all in one day. We
can work deck-by-deck.
The advantage of AES is that it is a known quantity, a standard, and
is called out as a requirement for government procurement in several
countries, including the US.
We're not called on to individually become amateur cryptographers on
this project. That would benefit absolutely no one. Instead we
should follow existing industry standards and best practices, one of
which is AES. And if there are other parts of the encryption pipeline
that can be improved, then let's do that as well.
-Rob
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 and thank you, TJ, for fact-checking what actually happens.
Folks, here is the issue.
The current builds of OOo-dev 3.4 (from Oracle) and all Apache OpenOffice 3.4 developer previews install with "Save with Password" pre-wired to encrypt using AES256-cbc and SHA256, and SHA256-1k digests, in conflict with the Blowfish CFB and SHA1, SHA1/1K digests that are all that down-level versions of OpenOffice-lineage and ODF 1.1 consumers can decrypt*d4e2h2*
, including Lotus Symphony, Libre Office prior to 3.5.x, and OpenOffice.or 3.3.0 (and earlier).
There is no dialog that notifies users that the encryption cannot be decrypted with earlier versions. Changing the behavior requires knowing how to manipulate configuration settings. There is no UI or Tools | Options dialog for this.
Fortunately, whichever default is used for Save with Password, both forms of encryption are accepted when opening a document.
THE PROPOSAL: Change the default so that the ODF 1.0/1.1/1.2-compatible and conformant encryption is used (Blowfish CFB and SHA1 for digests). Users who want to produce documents using AE256, despite the loss of interoperability with all consumers but those who can accept AE256 -- LO 3.5.x, OO.o-dev 3.4, and AOO 3.4+ -- can still change their configuration files to alter the default behavior on ODF 1.2 Save with Password.
THE PATCH: There is a simple two-line patch to reverse the default behavior when there is no over-ride in the user configuration. This is provided with r119090: <https://issues.apache.org/ooo/show_bug.cgi?id=119090>. This patch needs to be approved and accepted. (As a committer, I could have actually applied it. I didn't want that done without review first, so this is an RTC submission.)
THE BENEFIT: Non-expert users will not be surprised by the misleading failure of their password to work when using a machine with an older version of OO-line software. (The error message suggests that the file is damaged, not that the encryption is not understood.) In addition, files that are encrypted using AES will also be decryptable by these new releases without the user having to figure anything out.
THE DEBATE: There is extensive technical discussion on the Bugzilla comments. Here is a summary of what all of that technicality is about:
1. Some presume that switching to AES256 increases the security of the document.
2. The counter-argument is that it does no good to improve the security in parts of the encryption that do not improve the security of the weakest-link in the encryption technique. It will simply give a false sense of security where there is no improvement. The weak link in ODF 1.0/1.1/1.2 encryption is the way that passwords are used. Not in the encryption technique that is used for the document.
All of the extensive technical material is about explaining how it is that (2) is the case and that doing (1) simply inconveniences users and raises technical and reputation issues.
- Dennis
PS: An equivalent patch has also been contributed to LibreOffice for remedying the fact that the change to AES has been instituted in LO 3.5.x .)
-----Original Message-----
From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
Sent: Friday, March 23, 2012 11:26
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
On 3/23/2012 06:47, Andre Fischer wrote:
> Hi,
>
> there has been a longer discussion about this in the issue ([1]), most
> of it very technical. I previously thought that this is not a show
> stopper but I changed my mind but more for usability than technical
> reasons: I had expected that I could choose the encryption algorithm
> either in the save dialog or in the Tools->Options menu, but did not
> find a way to do it. Without this choice the user has two options:
>
> 1. Save as ODF 1.1
>
> 2. Not use encryption
>
>
> I don't find option 2 acceptable. Option 1 requires users to know that
> this solves their problem, i.e. that ODF 1.1 uses another encryption
> method than ODF 1.2. I did not know that before and assume that many
> others do not either.
>
> I see this now as a severe problem, even as a show stopper.
>
> Regards,
> Andre
+1
I agree that this should be a show stopper, so that the patch from
Dennis (or something to accomplish the same effect, and retain the
current Blowfish method as the default) should be integrated.
Given that, there are two more options to consider:
3. User change to config file, to use the new option.
I have suggested a writeup on this, but such instructions are much
better aimed at the (few?) users who want the "latest and greatest"
security option, and will do a little work to get it. (Does anybody know
what that file name is? Given that, I volunteer to update the Release
Notes.)
4. Macro to toggle the settings.
This could be distributed in a BASIC library (new or existing); no
extension necessary. User instructions to find and run the macro are
simple. I may be able to write this; preliminary investigation is
promising but not certain. I volunteer to try. There are several real
experts on this list, whom I might ask for help.
/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, Jürgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/26/12 11:21 AM, xia zhao wrote:
> 2012/3/26 Jürgen Schmidt<jo...@googlemail.com>
>
>> On 3/26/12 3:15 AM, Dennis E. Hamilton wrote:
>>
>>> TJ,
>>>
>>> I was doing some nosing around and, based on some information on the
>>> Community Forums (thank you Hagar), it looks like the settings are
>>> controlled in a file called registrymodifications.xcu, at least on Windows.
>>> The location will vary with different versions of windows.
>>>
>>> On windows, you can find one under the installed-user profile, such as
>>> Documents& Settings\orcmid\Application Data [a hidden file],
>>> OpenOffice/3/user/**registrymodification.xcu for any install since the
>>> AES256 has been instituted as default. the *.xcu is actually an XML file
>>> and you can find the settings by searching for "blowfish" and for "SHA1".
>>>
>>>
>>> How this works for Mac, Solaris, OS/2, and the various Linus and BSD
>>> builds, I have no idea.
>>>
>>
>> I think I have mentioned before that it is easy to provide an extension to
>> switch the relevant configuration settings.
>>
>> As the release manger I will accept the issue as critical enough to change
>> the default back for 3.4. For AOO 4.0 we will switch the default again and
>> will provide a GUI to allow the user the change it more easily.
>>
>> I give +1 for Juergen here, this issue is critical but I don't think it is
> critical enough to block AOO 3.4 ship from QA view, for one software, one
> new release may has some difference with previous release, even for the
> same feature. I don't think this issue locates at changing the default
> setting back for 3.4 or not, the point is which encryption algorithm is
> more polular and buy in by users.
I am not sure, most users don't care about the technical details and
they will be simply confused if it won't work any more with older office
versions.
We should make it better in AOO 4.0 and allow more flexibility
>
> But I agree offering user more flexibility by modifying the configuration
> file etc is one good idea.
>
> Lily
>
> For 3.4 we provide a mini extension that switch the default back to AES for
>> users who prefer this encryption algorithm.
I put a small oxt together, you can find it under
http://people.apache.org/~jsc/extensions/ODF12-Default-encryption-AES256-cbc.oxt
Feel free to test it, it should work in AOO3.4 only (in contains a
minimal and maximal version dependency)
Juergen
>>
>> Juergen
>>
>>
>>
>>
>>> - Dennis
>>>
>>> -----Original Message-----
>>> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
>>> Sent: Friday, March 23, 2012 11:26
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
>>> Down-Level Implementations
>>>
>>> [ ... ]
>>>
>>> ... options to consider:
>>>
>>> 3. User change to config file, to use the new option.
>>>
>>> I have suggested a writeup on this, but such instructions are much
>>> better aimed at the (few?) users who want the "latest and greatest"
>>> security option, and will do a little work to get it. (Does anybody know
>>> what that file name is? Given that, I volunteer to update the Release
>>> Notes.)
>>>
>>> 4. Macro to toggle the settings.
>>>
>>> This could be distributed in a BASIC library (new or existing); no
>>> extension necessary. User instructions to find and run the macro are
>>> simple. I may be able to write this; preliminary investigation is
>>> promising but not certain. I volunteer to try. There are several real
>>> experts on this list, whom I might ask for help.
>>>
>>> /tj/
>>>
>>>>
>>>>
>>>>
>>>> [1] https://issues.apache.org/ooo/**show_bug.cgi?id=119090<https://issues.apache.org/ooo/show_bug.cgi?id=119090>
>>>>
>>>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>>>
>>>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>>>
>>>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>>>> default provides a better security than before when I understand it
>>>>>>> correct. And if people detect potential problems they can save the
>>>>>>> document again with other settings.
>>>>>>>
>>>>>>> I agree that this is important for interoperability but no show
>>>>>>> stopper.
>>>>>>>
>>>>>>> Any other opinion?
>>>>>>>
>>>>>>> Juergen
>>>>>>>
>>>>>>>
>>>>>>> Hi, Jürgen,
>>>>>>
>>>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>>>> mention in the Release Notes; something like,
>>>>>>
>>>>>> PLEASE NOTE: the default options for [technical details here] should
>>>>>> provide your best /individual/ security. However, if you intend to
>>>>>> share
>>>>>> the document in secure fashion, the default mode cannot be read by
>>>>>> * previous versions of OpenOffice.org
>>>>>> * current versions of LibreOffice, at least through [version]
>>>>>> * Ms Office [version info]
>>>>>> For compatibility, use the options [details here].
>>>>>>
>>>>>>
>>>>> I agree that it make sense to mention it in the release notes.
>>>>>
>>>>> Any volunteer for updating the release notes?
>>>>>
>>>>> Juergen
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
Down-Level Implementations
Posted by xia zhao <li...@gmail.com>.
2012/3/26 Jürgen Schmidt <jo...@googlemail.com>
> On 3/26/12 3:15 AM, Dennis E. Hamilton wrote:
>
>> TJ,
>>
>> I was doing some nosing around and, based on some information on the
>> Community Forums (thank you Hagar), it looks like the settings are
>> controlled in a file called registrymodifications.xcu, at least on Windows.
>> The location will vary with different versions of windows.
>>
>> On windows, you can find one under the installed-user profile, such as
>> Documents& Settings\orcmid\Application Data [a hidden file],
>> OpenOffice/3/user/**registrymodification.xcu for any install since the
>> AES256 has been instituted as default. the *.xcu is actually an XML file
>> and you can find the settings by searching for "blowfish" and for "SHA1".
>>
>>
>> How this works for Mac, Solaris, OS/2, and the various Linus and BSD
>> builds, I have no idea.
>>
>
> I think I have mentioned before that it is easy to provide an extension to
> switch the relevant configuration settings.
>
> As the release manger I will accept the issue as critical enough to change
> the default back for 3.4. For AOO 4.0 we will switch the default again and
> will provide a GUI to allow the user the change it more easily.
>
> I give +1 for Juergen here, this issue is critical but I don't think it is
critical enough to block AOO 3.4 ship from QA view, for one software, one
new release may has some difference with previous release, even for the
same feature. I don't think this issue locates at changing the default
setting back for 3.4 or not, the point is which encryption algorithm is
more polular and buy in by users.
But I agree offering user more flexibility by modifying the configuration
file etc is one good idea.
Lily
For 3.4 we provide a mini extension that switch the default back to AES for
> users who prefer this encryption algorithm.
>
> Juergen
>
>
>
>
>> - Dennis
>>
>> -----Original Message-----
>> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
>> Sent: Friday, March 23, 2012 11:26
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
>> Down-Level Implementations
>>
>> [ ... ]
>>
>> ... options to consider:
>>
>> 3. User change to config file, to use the new option.
>>
>> I have suggested a writeup on this, but such instructions are much
>> better aimed at the (few?) users who want the "latest and greatest"
>> security option, and will do a little work to get it. (Does anybody know
>> what that file name is? Given that, I volunteer to update the Release
>> Notes.)
>>
>> 4. Macro to toggle the settings.
>>
>> This could be distributed in a BASIC library (new or existing); no
>> extension necessary. User instructions to find and run the macro are
>> simple. I may be able to write this; preliminary investigation is
>> promising but not certain. I volunteer to try. There are several real
>> experts on this list, whom I might ask for help.
>>
>> /tj/
>>
>>>
>>>
>>>
>>> [1] https://issues.apache.org/ooo/**show_bug.cgi?id=119090<https://issues.apache.org/ooo/show_bug.cgi?id=119090>
>>>
>>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>>
>>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>>
>>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>>> default provides a better security than before when I understand it
>>>>>> correct. And if people detect potential problems they can save the
>>>>>> document again with other settings.
>>>>>>
>>>>>> I agree that this is important for interoperability but no show
>>>>>> stopper.
>>>>>>
>>>>>> Any other opinion?
>>>>>>
>>>>>> Juergen
>>>>>>
>>>>>>
>>>>>> Hi, Jürgen,
>>>>>
>>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>>> mention in the Release Notes; something like,
>>>>>
>>>>> PLEASE NOTE: the default options for [technical details here] should
>>>>> provide your best /individual/ security. However, if you intend to
>>>>> share
>>>>> the document in secure fashion, the default mode cannot be read by
>>>>> * previous versions of OpenOffice.org
>>>>> * current versions of LibreOffice, at least through [version]
>>>>> * Ms Office [version info]
>>>>> For compatibility, use the options [details here].
>>>>>
>>>>>
>>>> I agree that it make sense to mention it in the release notes.
>>>>
>>>> Any volunteer for updating the release notes?
>>>>
>>>> Juergen
>>>>
>>>
>>>
>>>
>>
>>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/26/12 10:10 AM, Jürgen Schmidt wrote:
> On 3/26/12 3:15 AM, Dennis E. Hamilton wrote:
>> TJ,
>>
>> I was doing some nosing around and, based on some information on the
>> Community Forums (thank you Hagar), it looks like the settings are
>> controlled in a file called registrymodifications.xcu, at least on
>> Windows. The location will vary with different versions of windows.
>>
>> On windows, you can find one under the installed-user profile, such as
>> Documents& Settings\orcmid\Application Data [a hidden file],
>> OpenOffice/3/user/registrymodification.xcu for any install since the
>> AES256 has been instituted as default. the *.xcu is actually an XML
>> file and you can find the settings by searching for "blowfish" and for
>> "SHA1".
>>
>> How this works for Mac, Solaris, OS/2, and the various Linus and BSD
>> builds, I have no idea.
>
> I think I have mentioned before that it is easy to provide an extension
> to switch the relevant configuration settings.
>
> As the release manger I will accept the issue as critical enough to
> change the default back for 3.4. For AOO 4.0 we will switch the default
> again and will provide a GUI to allow the user the change it more easily.
>
> For 3.4 we provide a mini extension that switch the default back to AES
> for users who prefer this encryption algorithm.
>
please don't apply the patch in the issue, it won't work.
Juergen
> Juergen
>
>
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
>> Sent: Friday, March 23, 2012 11:26
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for
>> Down-Level Implementations
>>
>> [ ... ]
>>
>> ... options to consider:
>>
>> 3. User change to config file, to use the new option.
>>
>> I have suggested a writeup on this, but such instructions are much
>> better aimed at the (few?) users who want the "latest and greatest"
>> security option, and will do a little work to get it. (Does anybody know
>> what that file name is? Given that, I volunteer to update the Release
>> Notes.)
>>
>> 4. Macro to toggle the settings.
>>
>> This could be distributed in a BASIC library (new or existing); no
>> extension necessary. User instructions to find and run the macro are
>> simple. I may be able to write this; preliminary investigation is
>> promising but not certain. I volunteer to try. There are several real
>> experts on this list, whom I might ask for help.
>>
>> /tj/
>>>
>>>
>>>
>>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>>>
>>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I think issue 119090 is no show stopper from my point of view. The
>>>>>> new
>>>>>> default provides a better security than before when I understand it
>>>>>> correct. And if people detect potential problems they can save the
>>>>>> document again with other settings.
>>>>>>
>>>>>> I agree that this is important for interoperability but no show
>>>>>> stopper.
>>>>>>
>>>>>> Any other opinion?
>>>>>>
>>>>>> Juergen
>>>>>>
>>>>>>
>>>>> Hi, Jürgen,
>>>>>
>>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>>> mention in the Release Notes; something like,
>>>>>
>>>>> PLEASE NOTE: the default options for [technical details here] should
>>>>> provide your best /individual/ security. However, if you intend to
>>>>> share
>>>>> the document in secure fashion, the default mode cannot be read by
>>>>> * previous versions of OpenOffice.org
>>>>> * current versions of LibreOffice, at least through [version]
>>>>> * Ms Office [version info]
>>>>> For compatibility, use the options [details here].
>>>>>
>>>>
>>>> I agree that it make sense to mention it in the release notes.
>>>>
>>>> Any volunteer for updating the release notes?
>>>>
>>>> Juergen
>>>
>>>
>>
>>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/26/12 3:15 AM, Dennis E. Hamilton wrote:
> TJ,
>
> I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
>
> On windows, you can find one under the installed-user profile, such as Documents& Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
>
> How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
I think I have mentioned before that it is easy to provide an extension
to switch the relevant configuration settings.
As the release manger I will accept the issue as critical enough to
change the default back for 3.4. For AOO 4.0 we will switch the default
again and will provide a GUI to allow the user the change it more easily.
For 3.4 we provide a mini extension that switch the default back to AES
for users who prefer this encryption algorithm.
Juergen
>
> - Dennis
>
> -----Original Message-----
> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
> Sent: Friday, March 23, 2012 11:26
> To: ooo-dev@incubator.apache.org
> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> [ ... ]
>
> ... options to consider:
>
> 3. User change to config file, to use the new option.
>
> I have suggested a writeup on this, but such instructions are much
> better aimed at the (few?) users who want the "latest and greatest"
> security option, and will do a little work to get it. (Does anybody know
> what that file name is? Given that, I volunteer to update the Release
> Notes.)
>
> 4. Macro to toggle the settings.
>
> This could be distributed in a BASIC library (new or existing); no
> extension necessary. User instructions to find and run the macro are
> simple. I may be able to write this; preliminary investigation is
> promising but not certain. I volunteer to try. There are several real
> experts on this list, whom I might ask for help.
>
> /tj/
>>
>>
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>>
>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>> Hi,
>>>>>
>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>> default provides a better security than before when I understand it
>>>>> correct. And if people detect potential problems they can save the
>>>>> document again with other settings.
>>>>>
>>>>> I agree that this is important for interoperability but no show
>>>>> stopper.
>>>>>
>>>>> Any other opinion?
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>> Hi, Jürgen,
>>>>
>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>> mention in the Release Notes; something like,
>>>>
>>>> PLEASE NOTE: the default options for [technical details here] should
>>>> provide your best /individual/ security. However, if you intend to share
>>>> the document in secure fashion, the default mode cannot be read by
>>>> * previous versions of OpenOffice.org
>>>> * current versions of LibreOffice, at least through [version]
>>>> * Ms Office [version info]
>>>> For compatibility, use the options [details here].
>>>>
>>>
>>> I agree that it make sense to mention it in the release notes.
>>>
>>> Any volunteer for updating the release notes?
>>>
>>> Juergen
>>
>>
>
>
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I agree that preserving an existing registrymodifications.xcu is desirable.
There's no problem so long as the AOO 3.4 install is set to have the UseSHA1 and UseBlowfish options by default when there is no setting in registrymodifications.xcu.
If you are confident patching Common.xcs is sufficient for all of the paths where the default is not over-ridden, let's do it. It is probably easy to test whether there is an uncovered path to the default setting in the Save Options class constructor.
- Dennis
-----Original Message-----
From: Juergen Schmidt [mailto:jogischmidt@googlemail.com]
Sent: Tuesday, March 27, 2012 00:46
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
On 3/27/12 3:48 AM, Dennis E. Hamilton wrote:
> I confirmed my hypothesis. When AOO 3.4 is installed over the top of an existing (i.e., OpenOffice.org 3.3.0) installation, it does not updated the registrymodifications.xcu that is already there. Since there are no settings of options for Save As Password use of SHA1 and Blowfish there, none are there after the AOO 3.4 install. That means only the program-set defaults will kick in and the user will be converted to "Save with Password" using SHA256/K checksums and AES256 CBC encryption.
>
The update installs over an existing user installation where a user have
made some local changes that we don't overwrite. Everything else would
be probably surprising to the users who have potentially changed a lot
of default values.
I think the behaviour is want the user expect. And the config entries
are read from the configuration anyway independent from the
initialization in the code. So either the default values from Common.xcs
(finallly main.xcd) are used or the overwritten value in the user config
layer.
I don't see a problem here.
Juergen
> I verified this with AOO 3.4 r1303653 atop OO.o 3.3.0.
>
> - Dennis
>
> PS: I also confirmed that LibreOffice 3.5.0rc3 is adding chaff to XML files that are compressed and encrypted, preventing easy access to known plaintexts for attacking the encryptions in the ODF package. (There is a discussion of chaff, among other technicalities at<https://issues.apache.org/ooo/show_bug.cgi?id=119090>.)
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Monday, March 26, 2012 17:16
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com; jsc@apache.org
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> I did more experiments with AOO-dev 3.4 and LO 3.5.0rc3 which I happened to have installed where it was easy to test them together.
>
> TEST RESULTS
>
> 1. It is possible to change the default behavior of AOO-dev 3.4 and LO 3.5.0rc3 (both of which produce AES 256 CBC and SHA256-1k encryptions by default) by setting options in registrymodifications.xcu.
>
> 2. If registrymodifications.xcu is deleted, a new one is created *but* it has *no* settings for the SHA1 and Blowfish in ODF12 and these installations *revert* to AES256 CBC and SHA256-1k even if their last use was with options set for Blowfish CFB and SHA1/1K.
>
> HYPOTHESIS **CONFIRMED**: If an install is done on top of a previous installation not supporting AES to update to a later version, no settings for this will be added to the "legacy" registrymodifications.xcu and the default will go into effect: encryptions will start being done in AES256, surprise, surprise.
>
> RECOMMENDATION:
>
> 1. It looks like registrymodification.xcu is the place where a tool or script can do the job when it comes to setting/changing the desired option.
>
> 2. It looks like there must be code changes to set the default to Blowfish and SHA1/1K within the application to cover the case where registrymodification.xcu doesn't specify an option either way.
>
> This last may be in Common.xcs but I am betting that the assured default setting is in the constructor initial values in savopt.cxx. Why? Because that class holds the options and setters and getters for them. Other software uses the setters when processing configuration parameters from elsewhere, with the default value delivered by the getter when no configuration parameter provides a change. My money is on that being the place.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, March 25, 2012 18:15
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> TJ,
>
> I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
>
> On windows, you can find one under the installed-user profile, such as Documents& Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
>
> How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
>
> - Dennis
>
> -----Original Message-----
> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
> Sent: Friday, March 23, 2012 11:26
> To: ooo-dev@incubator.apache.org
> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> [ ... ]
>
> ... options to consider:
>
> 3. User change to config file, to use the new option.
>
> I have suggested a writeup on this, but such instructions are much
> better aimed at the (few?) users who want the "latest and greatest"
> security option, and will do a little work to get it. (Does anybody know
> what that file name is? Given that, I volunteer to update the Release
> Notes.)
>
> 4. Macro to toggle the settings.
>
> This could be distributed in a BASIC library (new or existing); no
> extension necessary. User instructions to find and run the macro are
> simple. I may be able to write this; preliminary investigation is
> promising but not certain. I volunteer to try. There are several real
> experts on this list, whom I might ask for help.
>
> /tj/
>>
>>
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>>
>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>> Hi,
>>>>>
>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>> default provides a better security than before when I understand it
>>>>> correct. And if people detect potential problems they can save the
>>>>> document again with other settings.
>>>>>
>>>>> I agree that this is important for interoperability but no show
>>>>> stopper.
>>>>>
>>>>> Any other opinion?
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>> Hi, Jürgen,
>>>>
>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>> mention in the Release Notes; something like,
>>>>
>>>> PLEASE NOTE: the default options for [technical details here] should
>>>> provide your best /individual/ security. However, if you intend to share
>>>> the document in secure fashion, the default mode cannot be read by
>>>> * previous versions of OpenOffice.org
>>>> * current versions of LibreOffice, at least through [version]
>>>> * Ms Office [version info]
>>>> For compatibility, use the options [details here].
>>>>
>>>
>>> I agree that it make sense to mention it in the release notes.
>>>
>>> Any volunteer for updating the release notes?
>>>
>>> Juergen
>>
>>
>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Juergen Schmidt <jo...@googlemail.com>.
On 3/27/12 3:48 AM, Dennis E. Hamilton wrote:
> I confirmed my hypothesis. When AOO 3.4 is installed over the top of an existing (i.e., OpenOffice.org 3.3.0) installation, it does not updated the registrymodifications.xcu that is already there. Since there are no settings of options for Save As Password use of SHA1 and Blowfish there, none are there after the AOO 3.4 install. That means only the program-set defaults will kick in and the user will be converted to "Save with Password" using SHA256/K checksums and AES256 CBC encryption.
>
The update installs over an existing user installation where a user have
made some local changes that we don't overwrite. Everything else would
be probably surprising to the users who have potentially changed a lot
of default values.
I think the behaviour is want the user expect. And the config entries
are read from the configuration anyway independent from the
initialization in the code. So either the default values from Common.xcs
(finallly main.xcd) are used or the overwritten value in the user config
layer.
I don't see a problem here.
Juergen
> I verified this with AOO 3.4 r1303653 atop OO.o 3.3.0.
>
> - Dennis
>
> PS: I also confirmed that LibreOffice 3.5.0rc3 is adding chaff to XML files that are compressed and encrypted, preventing easy access to known plaintexts for attacking the encryptions in the ODF package. (There is a discussion of chaff, among other technicalities at<https://issues.apache.org/ooo/show_bug.cgi?id=119090>.)
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Monday, March 26, 2012 17:16
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com; jsc@apache.org
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> I did more experiments with AOO-dev 3.4 and LO 3.5.0rc3 which I happened to have installed where it was easy to test them together.
>
> TEST RESULTS
>
> 1. It is possible to change the default behavior of AOO-dev 3.4 and LO 3.5.0rc3 (both of which produce AES 256 CBC and SHA256-1k encryptions by default) by setting options in registrymodifications.xcu.
>
> 2. If registrymodifications.xcu is deleted, a new one is created *but* it has *no* settings for the SHA1 and Blowfish in ODF12 and these installations *revert* to AES256 CBC and SHA256-1k even if their last use was with options set for Blowfish CFB and SHA1/1K.
>
> HYPOTHESIS **CONFIRMED**: If an install is done on top of a previous installation not supporting AES to update to a later version, no settings for this will be added to the "legacy" registrymodifications.xcu and the default will go into effect: encryptions will start being done in AES256, surprise, surprise.
>
> RECOMMENDATION:
>
> 1. It looks like registrymodification.xcu is the place where a tool or script can do the job when it comes to setting/changing the desired option.
>
> 2. It looks like there must be code changes to set the default to Blowfish and SHA1/1K within the application to cover the case where registrymodification.xcu doesn't specify an option either way.
>
> This last may be in Common.xcs but I am betting that the assured default setting is in the constructor initial values in savopt.cxx. Why? Because that class holds the options and setters and getters for them. Other software uses the setters when processing configuration parameters from elsewhere, with the default value delivered by the getter when no configuration parameter provides a change. My money is on that being the place.
>
> - Dennis
>
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Sunday, March 25, 2012 18:15
> To: ooo-dev@incubator.apache.org
> Cc: tjfrazier@cfl.rr.com
> Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> TJ,
>
> I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
>
> On windows, you can find one under the installed-user profile, such as Documents& Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
>
> How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
>
> - Dennis
>
> -----Original Message-----
> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
> Sent: Friday, March 23, 2012 11:26
> To: ooo-dev@incubator.apache.org
> Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
>
> [ ... ]
>
> ... options to consider:
>
> 3. User change to config file, to use the new option.
>
> I have suggested a writeup on this, but such instructions are much
> better aimed at the (few?) users who want the "latest and greatest"
> security option, and will do a little work to get it. (Does anybody know
> what that file name is? Given that, I volunteer to update the Release
> Notes.)
>
> 4. Macro to toggle the settings.
>
> This could be distributed in a BASIC library (new or existing); no
> extension necessary. User instructions to find and run the macro are
> simple. I may be able to write this; preliminary investigation is
> promising but not certain. I volunteer to try. There are several real
> experts on this list, whom I might ask for help.
>
> /tj/
>>
>>
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>>
>> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>>> Hi,
>>>>>
>>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>>> default provides a better security than before when I understand it
>>>>> correct. And if people detect potential problems they can save the
>>>>> document again with other settings.
>>>>>
>>>>> I agree that this is important for interoperability but no show
>>>>> stopper.
>>>>>
>>>>> Any other opinion?
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>> Hi, Jürgen,
>>>>
>>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>>> mention in the Release Notes; something like,
>>>>
>>>> PLEASE NOTE: the default options for [technical details here] should
>>>> provide your best /individual/ security. However, if you intend to share
>>>> the document in secure fashion, the default mode cannot be read by
>>>> * previous versions of OpenOffice.org
>>>> * current versions of LibreOffice, at least through [version]
>>>> * Ms Office [version info]
>>>> For compatibility, use the options [details here].
>>>>
>>>
>>> I agree that it make sense to mention it in the release notes.
>>>
>>> Any volunteer for updating the release notes?
>>>
>>> Juergen
>>
>>
>
>
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I confirmed my hypothesis. When AOO 3.4 is installed over the top of an existing (i.e., OpenOffice.org 3.3.0) installation, it does not updated the registrymodifications.xcu that is already there. Since there are no settings of options for Save As Password use of SHA1 and Blowfish there, none are there after the AOO 3.4 install. That means only the program-set defaults will kick in and the user will be converted to "Save with Password" using SHA256/K checksums and AES256 CBC encryption.
I verified this with AOO 3.4 r1303653 atop OO.o 3.3.0.
- Dennis
PS: I also confirmed that LibreOffice 3.5.0rc3 is adding chaff to XML files that are compressed and encrypted, preventing easy access to known plaintexts for attacking the encryptions in the ODF package. (There is a discussion of chaff, among other technicalities at <https://issues.apache.org/ooo/show_bug.cgi?id=119090>.)
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Monday, March 26, 2012 17:16
To: ooo-dev@incubator.apache.org
Cc: tjfrazier@cfl.rr.com; jsc@apache.org
Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
I did more experiments with AOO-dev 3.4 and LO 3.5.0rc3 which I happened to have installed where it was easy to test them together.
TEST RESULTS
1. It is possible to change the default behavior of AOO-dev 3.4 and LO 3.5.0rc3 (both of which produce AES 256 CBC and SHA256-1k encryptions by default) by setting options in registrymodifications.xcu.
2. If registrymodifications.xcu is deleted, a new one is created *but* it has *no* settings for the SHA1 and Blowfish in ODF12 and these installations *revert* to AES256 CBC and SHA256-1k even if their last use was with options set for Blowfish CFB and SHA1/1K.
HYPOTHESIS **CONFIRMED**: If an install is done on top of a previous installation not supporting AES to update to a later version, no settings for this will be added to the "legacy" registrymodifications.xcu and the default will go into effect: encryptions will start being done in AES256, surprise, surprise.
RECOMMENDATION:
1. It looks like registrymodification.xcu is the place where a tool or script can do the job when it comes to setting/changing the desired option.
2. It looks like there must be code changes to set the default to Blowfish and SHA1/1K within the application to cover the case where registrymodification.xcu doesn't specify an option either way.
This last may be in Common.xcs but I am betting that the assured default setting is in the constructor initial values in savopt.cxx. Why? Because that class holds the options and setters and getters for them. Other software uses the setters when processing configuration parameters from elsewhere, with the default value delivered by the getter when no configuration parameter provides a change. My money is on that being the place.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Sunday, March 25, 2012 18:15
To: ooo-dev@incubator.apache.org
Cc: tjfrazier@cfl.rr.com
Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
TJ,
I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
On windows, you can find one under the installed-user profile, such as Documents & Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
- Dennis
-----Original Message-----
From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
Sent: Friday, March 23, 2012 11:26
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
[ ... ]
... options to consider:
3. User change to config file, to use the new option.
I have suggested a writeup on this, but such instructions are much
better aimed at the (few?) users who want the "latest and greatest"
security option, and will do a little work to get it. (Does anybody know
what that file name is? Given that, I volunteer to update the Release
Notes.)
4. Macro to toggle the settings.
This could be distributed in a BASIC library (new or existing); no
extension necessary. User instructions to find and run the macro are
simple. I may be able to write this; preliminary investigation is
promising but not certain. I volunteer to try. There are several real
experts on this list, whom I might ask for help.
/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, Jürgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I did more experiments with AOO-dev 3.4 and LO 3.5.0rc3 which I happened to have installed where it was easy to test them together.
TEST RESULTS
1. It is possible to change the default behavior of AOO-dev 3.4 and LO 3.5.0rc3 (both of which produce AES 256 CBC and SHA256-1k encryptions by default) by setting options in registrymodifications.xcu.
2. If registrymodifications.xcu is deleted, a new one is created *but* it has *no* settings for the SHA1 and Blowfish in ODF12 and these installations *revert* to AES256 CBC and SHA256-1k even if their last use was with options set for Blowfish CFB and SHA1/1K.
HYPOTHESIS: If an install is done on top of a previous installation not supporting AES to update to a later version, no settings for this will be added to the "legacy" registrymodifications.xcu and the default will go into effect: encryptions will start being done in AES256, surprise, surprise.
I haven't tested this integration case to confirm this hypothesis yet.
RECOMMENDATION:
1. It looks like registrymodification.xcu is the place where a tool or script can do the job when it comes to setting/changing the desired option.
2. It looks like there must be code changes to set the default to Blowfish and SHA1/1K within the application to cover the case where registrymodification.xcu doesn't specify an option either way.
This last may be in Common.xcs but I am betting that the assured default setting is in the constructor initial values in savopt.cxx. Why? Because that class holds the options and setters and getters for them. Other software uses the setters when processing configuration parameters from elsewhere, with the default value delivered by the getter when no configuration parameter provides a change. My money is on that being the place.
- Dennis
-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Sunday, March 25, 2012 18:15
To: ooo-dev@incubator.apache.org
Cc: tjfrazier@cfl.rr.com
Subject: RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
TJ,
I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
On windows, you can find one under the installed-user profile, such as Documents & Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
- Dennis
-----Original Message-----
From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
Sent: Friday, March 23, 2012 11:26
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
[ ... ]
... options to consider:
3. User change to config file, to use the new option.
I have suggested a writeup on this, but such instructions are much
better aimed at the (few?) users who want the "latest and greatest"
security option, and will do a little work to get it. (Does anybody know
what that file name is? Given that, I volunteer to update the Release
Notes.)
4. Macro to toggle the settings.
This could be distributed in a BASIC library (new or existing); no
extension necessary. User instructions to find and run the macro are
simple. I may be able to write this; preliminary investigation is
promising but not certain. I volunteer to try. There are several real
experts on this list, whom I might ask for help.
/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, Jürgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>
RE: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
Posted by "Dennis E. Hamilton" <de...@acm.org>.
TJ,
I was doing some nosing around and, based on some information on the Community Forums (thank you Hagar), it looks like the settings are controlled in a file called registrymodifications.xcu, at least on Windows. The location will vary with different versions of windows.
On windows, you can find one under the installed-user profile, such as Documents & Settings\orcmid\Application Data [a hidden file], OpenOffice/3/user/registrymodification.xcu for any install since the AES256 has been instituted as default. the *.xcu is actually an XML file and you can find the settings by searching for "blowfish" and for "SHA1".
How this works for Mac, Solaris, OS/2, and the various Linus and BSD builds, I have no idea.
- Dennis
-----Original Message-----
From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
Sent: Friday, March 23, 2012 11:26
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level Implementations
[ ... ]
... options to consider:
3. User change to config file, to use the new option.
I have suggested a writeup on this, but such instructions are much
better aimed at the (few?) users who want the "latest and greatest"
security option, and will do a little work to get it. (Does anybody know
what that file name is? Given that, I volunteer to update the Release
Notes.)
4. Macro to toggle the settings.
This could be distributed in a BASIC library (new or existing); no
extension necessary. User instructions to find and run the macro are
simple. I may be able to write this; preliminary investigation is
promising but not certain. I volunteer to try. There are several real
experts on this list, whom I might ask for help.
/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, Jürgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 3/23/2012 06:47, Andre Fischer wrote:
> Hi,
>
> there has been a longer discussion about this in the issue ([1]), most
> of it very technical. I previously thought that this is not a show
> stopper but I changed my mind but more for usability than technical
> reasons: I had expected that I could choose the encryption algorithm
> either in the save dialog or in the Tools->Options menu, but did not
> find a way to do it. Without this choice the user has two options:
>
> 1. Save as ODF 1.1
>
> 2. Not use encryption
>
>
> I don't find option 2 acceptable. Option 1 requires users to know that
> this solves their problem, i.e. that ODF 1.1 uses another encryption
> method than ODF 1.2. I did not know that before and assume that many
> others do not either.
>
> I see this now as a severe problem, even as a show stopper.
>
> Regards,
> Andre
+1
I agree that this should be a show stopper, so that the patch from
Dennis (or something to accomplish the same effect, and retain the
current Blowfish method as the default) should be integrated.
Given that, there are two more options to consider:
3. User change to config file, to use the new option.
I have suggested a writeup on this, but such instructions are much
better aimed at the (few?) users who want the "latest and greatest"
security option, and will do a little work to get it. (Does anybody know
what that file name is? Given that, I volunteer to update the Release
Notes.)
4. Macro to toggle the settings.
This could be distributed in a BASIC library (new or existing); no
extension necessary. User instructions to find and run the macro are
simple. I may be able to write this; preliminary investigation is
promising but not certain. I volunteer to try. There are several real
experts on this list, whom I might ask for help.
/tj/
>
>
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
>
> On 19.03.2012 14:48, Jürgen Schmidt wrote:
>> On 3/19/12 2:16 PM, TJ Frazier wrote:
>>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>>> Hi,
>>>>
>>>> I think issue 119090 is no show stopper from my point of view. The new
>>>> default provides a better security than before when I understand it
>>>> correct. And if people detect potential problems they can save the
>>>> document again with other settings.
>>>>
>>>> I agree that this is important for interoperability but no show
>>>> stopper.
>>>>
>>>> Any other opinion?
>>>>
>>>> Juergen
>>>>
>>>>
>>> Hi, Jürgen,
>>>
>>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>>> mention in the Release Notes; something like,
>>>
>>> PLEASE NOTE: the default options for [technical details here] should
>>> provide your best /individual/ security. However, if you intend to share
>>> the document in secure fashion, the default mode cannot be read by
>>> * previous versions of OpenOffice.org
>>> * current versions of LibreOffice, at least through [version]
>>> * Ms Office [version info]
>>> For compatibility, use the options [details here].
>>>
>>
>> I agree that it make sense to mention it in the release notes.
>>
>> Any volunteer for updating the release notes?
>>
>> Juergen
>
>
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Andre Fischer <af...@a-w-f.de>.
Hi,
there has been a longer discussion about this in the issue ([1]), most
of it very technical. I previously thought that this is not a show
stopper but I changed my mind but more for usability than technical
reasons: I had expected that I could choose the encryption algorithm
either in the save dialog or in the Tools->Options menu, but did not
find a way to do it. Without this choice the user has two options:
1. Save as ODF 1.1
2. Not use encryption
I don't find option 2 acceptable. Option 1 requires users to know that
this solves their problem, i.e. that ODF 1.1 uses another encryption
method than ODF 1.2. I did not know that before and assume that many
others do not either.
I see this now as a severe problem, even as a show stopper.
Regards,
Andre
[1] https://issues.apache.org/ooo/show_bug.cgi?id=119090
On 19.03.2012 14:48, Jürgen Schmidt wrote:
> On 3/19/12 2:16 PM, TJ Frazier wrote:
>> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>>> Hi,
>>>
>>> I think issue 119090 is no show stopper from my point of view. The new
>>> default provides a better security than before when I understand it
>>> correct. And if people detect potential problems they can save the
>>> document again with other settings.
>>>
>>> I agree that this is important for interoperability but no show stopper.
>>>
>>> Any other opinion?
>>>
>>> Juergen
>>>
>>>
>> Hi, Jürgen,
>>
>> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
>> mention in the Release Notes; something like,
>>
>> PLEASE NOTE: the default options for [technical details here] should
>> provide your best /individual/ security. However, if you intend to share
>> the document in secure fashion, the default mode cannot be read by
>> * previous versions of OpenOffice.org
>> * current versions of LibreOffice, at least through [version]
>> * Ms Office [version info]
>> For compatibility, use the options [details here].
>>
>
> I agree that it make sense to mention it in the release notes.
>
> Any volunteer for updating the release notes?
>
> Juergen
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/19/12 2:16 PM, TJ Frazier wrote:
> On 3/19/2012 08:48, Jürgen Schmidt wrote:
>> Hi,
>>
>> I think issue 119090 is no show stopper from my point of view. The new
>> default provides a better security than before when I understand it
>> correct. And if people detect potential problems they can save the
>> document again with other settings.
>>
>> I agree that this is important for interoperability but no show stopper.
>>
>> Any other opinion?
>>
>> Juergen
>>
>>
> Hi, Jürgen,
>
> Like Dennis, I'm nervous about this. Perhaps we can handle it with a
> mention in the Release Notes; something like,
>
> PLEASE NOTE: the default options for [technical details here] should
> provide your best /individual/ security. However, if you intend to share
> the document in secure fashion, the default mode cannot be read by
> * previous versions of OpenOffice.org
> * current versions of LibreOffice, at least through [version]
> * Ms Office [version info]
> For compatibility, use the options [details here].
>
I agree that it make sense to mention it in the release notes.
Any volunteer for updating the release notes?
Juergen
Re: [RELEASE,CODE]: Bug 119090 - Default Encryption Fails for Down-Level
Implementations
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 3/19/2012 08:48, Jürgen Schmidt wrote:
> Hi,
>
> I think issue 119090 is no show stopper from my point of view. The new
> default provides a better security than before when I understand it
> correct. And if people detect potential problems they can save the
> document again with other settings.
>
> I agree that this is important for interoperability but no show stopper.
>
> Any other opinion?
>
> Juergen
>
>
Hi, Jürgen,
Like Dennis, I'm nervous about this. Perhaps we can handle it with a
mention in the Release Notes; something like,
PLEASE NOTE: the default options for [technical details here] should
provide your best /individual/ security. However, if you intend to share
the document in secure fashion, the default mode cannot be read by
* previous versions of OpenOffice.org
* current versions of LibreOffice, at least through [version]
* Ms Office [version info]
For compatibility, use the options [details here].
/tj/, his 2¢