Re: failed to build aoo420 dev on win32

2016-06-10 Thread Damjan Jovanovic 
On Fri, Jun 10, 2016 at 10:03 PM, Oliver Brinzing 
wrote:

> Hi Damjan,
>
> thanks for fixing the two build breakers. i started a debug build 3 hours
> ago
> i have 2 errors till now:
>

Hi Oliver


> >> windows build breaks in module formula
> >> https://bz.apache.org/ooo/show_bug.cgi?id=126916
>
>
I've attached a possible patch for this, but won't be able to test it for a
while. Does it work for you?


> and a new one in module "extensions",  source/activex/main
>
> C:\build_tmp\trunk\main\solver\420\wntmsci12\inc\osl/endian.h(160) : fatal
> error C1189: #error : undetermined endianness
> dmake:  Error code 2, while making
> '../../../wntmsci12/slo/x64/so_activex.obj'
>
>
Are you building on x64? AOO only supports 32 bit Windows.


> Regards
> Oliver
>
> --
>
> error in module "extensions",  source/activex/main
>
> : &&
>  
> PATH=/cygdrive/c/build_tmp/trunk/main/solver/420/wntmsci12/bin${PATH:+:${PATH}}
> C:/build_tmp/trunk/main/solver/420/wntmsci12/bin/makedepend -f -
> -p../../../wntmsci12/res -o.res -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL
> -D_STLP_DEBUG -D_X86_=1 -D_CRT_SECURE_NO_DEPRECATE
> -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK
> -DBOOST_MEM_FN_ENABLE_CDECL -D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500
> -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG -DDBG_UTIL
> -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA   -DDLLPOSTFIX= -I. -I../../../inc
> -I../inc -I../../../WIN/inc -I../../../wntmsci12/inc
> -IC:/build_tmp/trunk/main/solenv/inc so_activex.rc >>
> ../../../wntmsci12/misc/so_activex.dprc
> cat ../../../wntmsci12/res/so_activex.res >
> ../../../wntmsci12/misc/so_activex.res
> Making:so_activex.dll
> link /MACHINE:IX86 /IGNORE:4102 /IGNORE:4197 @C:/build/cygwin/tmp/mk4lyHC8
> if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then mt.exe
> -manifest ../../../wntmsci12/bin/so_activex.dll.manifest
> -outputresource:../../../wntmsci12/bin/so_activex.dll\;2 ; fi
> if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then /bin/rm -f
> ../../../wntmsci12/bin/so_activex.dll.manifest ; fi
> if [ -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ] ; then /bin/rm
> -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ; fi
> Microsoft (R) Incremental Linker Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
> -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -DEBUG -DEBUG -safeseh
> -nxcompat -dynamicbase /SUBSYSTEM:CONSOLE /DLL
> -out:../../../wntmsci12/bin/so_activex.dll
> -map:../../../wntmsci12/misc/so_activex.map -def:so_activex.def
> -implib:../../../wntmsci12/lib/iso_activex_t1.lib
> ../../../wntmsci12/slo/so_activex.obj ../../../wntmsci12/slo/SOActiveX.obj
> ../../../wntmsci12/slo/SOComWindowPeer.obj
> ../../../wntmsci12/slo/SODispatchInterceptor.obj
> ../../../wntmsci12/slo/SOActionsApproval.obj
> ../../../wntmsci12/slo/StdAfx2.obj uuid.lib advapi32.lib ole32.lib
> oleaut32.lib gdi32.lib urlmon.lib shlwapi.lib
> C:/WinDDK/760016~1.1/lib/ATL/i386/atls.lib
> C:/WinDDK/760016~1.1/lib/ATL/i386/atlthunk.lib msvcrt.lib msvcprt.lib
> kernel32.lib user32.lib oldnames.lib ../../../wntmsci12/misc/so_activex.res
> --
> Making: ../../../wntmsci12/slo/x64/so_activex.obj
> so_activex.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should
> not be assigned an ordinal
> so_activex.def : warning LNK4222: exported symbol 'DllGetClassObject'
> should not be assigned an ordinal
> so_activex.def : warning LNK4222: exported symbol 'DllRegisterServer'
> should not be assigned an ordinal
> so_activex.def : warning LNK4222: exported symbol 'DllUnregisterServer'
> should not be assigned an ordinal
>Creating library ../../../wntmsci12/lib/iso_activex_t1.lib and object
> ../../../wntmsci12/lib/iso_activex_t1.exp
> mkdir.exe ../../../wntmsci12/slo/x64/
> C:/PROGRA~2/MICROS~1.0/VC/bin/amd64/cl.exe -c -nologo -Gs  -Zm500
> -Zc:wchar_t- -GR -Zi -Fd../../../wntmsci12/misc/x64/so_activex.pdb  -Ob1
> -I. -I../../../wntmsci12/inc/so_activex -IC:/WinDDK/760016~1.1/inc/atl71
> -I../../../wntmsci12/misc -I../inc -I../../../inc/pch -I../../../inc
> -I../../../WIN/inc -I../../../wntmsci12/inc -I.
> -IC:/build_tmp/trunk/main/solver/420/wntmsci12/incdont_use_stl
> -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/external
> -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc
> -IC:/build_tmp/trunk/main/solenv/wntmsci12/inc
> -IC:/build_tmp/trunk/main/solenv/inc -IC:/build_tmp/trunk/main/res
> -IC:/build_tmp/trunk/main/tools/inc
> -IC:/build_tmp/trunk/main/comphelper/inc
> -IC:/PROGRA~2/Java/JDK17~1.0/include/win32
> -IC:/PROGRA~2/Java/JDK17~1.0/include
> -IC:/PROGRA~1/MICROS~1/Windows/v7.0/include
> -IC:/PROGRA~2/MICROS~1.0/VC/include -IC:/PROGRA~2/MICROS~1/include
> -IC:/PROGRA~2/MICROS~1/include
> -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/offuh -I. -I../../../res
> -I.  -MT -DWIN32 -D_AMD64_=1 -D_CRT_SECURE_NO_DEPRECATE
> -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS

Re: failed to build aoo420 dev on win32

2016-06-10 Thread Oliver Brinzing 

Hi Damjan,

thanks for fixing the two build breakers. i started a debug build 3 hours ago
i have 2 errors till now:

>> windows build breaks in module formula
>> https://bz.apache.org/ooo/show_bug.cgi?id=126916

and a new one in module "extensions",  source/activex/main

C:\build_tmp\trunk\main\solver\420\wntmsci12\inc\osl/endian.h(160) : fatal error C1189: #error : 
undetermined endianness

dmake:  Error code 2, while making '../../../wntmsci12/slo/x64/so_activex.obj'

Regards
Oliver

--

error in module "extensions",  source/activex/main

: && PATH=/cygdrive/c/build_tmp/trunk/main/solver/420/wntmsci12/bin${PATH:+:${PATH}} 
C:/build_tmp/trunk/main/solver/420/wntmsci12/bin/makedepend -f - -p../../../wntmsci12/res -o.res 
-DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL -D_STLP_DEBUG -D_X86_=1 -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK -DBOOST_MEM_FN_ENABLE_CDECL 
-D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG 
-DDBG_UTIL -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA   -DDLLPOSTFIX= -I. -I../../../inc -I../inc 
-I../../../WIN/inc -I../../../wntmsci12/inc -IC:/build_tmp/trunk/main/solenv/inc so_activex.rc >> 
../../../wntmsci12/misc/so_activex.dprc

cat ../../../wntmsci12/res/so_activex.res > 
../../../wntmsci12/misc/so_activex.res
Making:so_activex.dll
link /MACHINE:IX86 /IGNORE:4102 /IGNORE:4197 @C:/build/cygwin/tmp/mk4lyHC8
if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then mt.exe  -manifest 
../../../wntmsci12/bin/so_activex.dll.manifest 
-outputresource:../../../wntmsci12/bin/so_activex.dll\;2 ; fi
if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then /bin/rm -f 
../../../wntmsci12/bin/so_activex.dll.manifest ; fi
if [ -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ] ; then /bin/rm -f 
../../../wntmsci12/bin/so_activex.dll.tmanifest ; fi

Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.
-safeseh -nxcompat -dynamicbase -NODEFAULTLIB -DEBUG -DEBUG -safeseh -nxcompat -dynamicbase 
/SUBSYSTEM:CONSOLE /DLL -out:../../../wntmsci12/bin/so_activex.dll 
-map:../../../wntmsci12/misc/so_activex.map -def:so_activex.def 
-implib:../../../wntmsci12/lib/iso_activex_t1.lib ../../../wntmsci12/slo/so_activex.obj 
../../../wntmsci12/slo/SOActiveX.obj ../../../wntmsci12/slo/SOComWindowPeer.obj 
../../../wntmsci12/slo/SODispatchInterceptor.obj ../../../wntmsci12/slo/SOActionsApproval.obj 
../../../wntmsci12/slo/StdAfx2.obj uuid.lib advapi32.lib ole32.lib oleaut32.lib gdi32.lib urlmon.lib 
shlwapi.lib C:/WinDDK/760016~1.1/lib/ATL/i386/atls.lib 
C:/WinDDK/760016~1.1/lib/ATL/i386/atlthunk.lib msvcrt.lib msvcprt.lib kernel32.lib user32.lib 
oldnames.lib ../../../wntmsci12/misc/so_activex.res

--
Making: ../../../wntmsci12/slo/x64/so_activex.obj
so_activex.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not 
be assigned an ordinal
so_activex.def : warning LNK4222: exported symbol 'DllGetClassObject' should 
not be assigned an ordinal
so_activex.def : warning LNK4222: exported symbol 'DllRegisterServer' should 
not be assigned an ordinal
so_activex.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an 
ordinal
   Creating library ../../../wntmsci12/lib/iso_activex_t1.lib and object 
../../../wntmsci12/lib/iso_activex_t1.exp

mkdir.exe ../../../wntmsci12/slo/x64/
C:/PROGRA~2/MICROS~1.0/VC/bin/amd64/cl.exe -c -nologo -Gs  -Zm500 -Zc:wchar_t- -GR -Zi 
-Fd../../../wntmsci12/misc/x64/so_activex.pdb  -Ob1 -I. -I../../../wntmsci12/inc/so_activex 
-IC:/WinDDK/760016~1.1/inc/atl71 -I../../../wntmsci12/misc -I../inc -I../../../inc/pch 
-I../../../inc -I../../../WIN/inc -I../../../wntmsci12/inc -I. 
-IC:/build_tmp/trunk/main/solver/420/wntmsci12/incdont_use_stl 
-IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/external 
-IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc -IC:/build_tmp/trunk/main/solenv/wntmsci12/inc 
-IC:/build_tmp/trunk/main/solenv/inc -IC:/build_tmp/trunk/main/res 
-IC:/build_tmp/trunk/main/tools/inc -IC:/build_tmp/trunk/main/comphelper/inc 
-IC:/PROGRA~2/Java/JDK17~1.0/include/win32 -IC:/PROGRA~2/Java/JDK17~1.0/include 
-IC:/PROGRA~1/MICROS~1/Windows/v7.0/include -IC:/PROGRA~2/MICROS~1.0/VC/include 
-IC:/PROGRA~2/MICROS~1/include -IC:/PROGRA~2/MICROS~1/include 
-IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/offuh -I. -I../../../res -I.  -MT -DWIN32 
-D_AMD64_=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS 
-DDEBUG -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL -D_STLP_DEBUG -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK -DBOOST_MEM_FN_ENABLE_CDECL 
-D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG 
-DDBG_UTIL -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA  -D_MT -D_DLL -D_MT -D_DLL   -DEXCEPTIONS_OFF

Re: A Question about Open Office Password Protected Text Documents

2016-06-10 Thread Roger Bentley 

Dear Ms Shanahan

Thank you very much for your email and comments.

They are greatly appreciated.

Yours sincerely

Roger Bentley


-Original Message- 
From: Patricia Shanahan

Sent: Friday, June 10, 2016 3:51 PM
To: dev@openoffice.apache.org
Subject: Re: A Question about Open Office Password Protected Text Documents

That said, if I had a set of business-critical documents, I would test
some sample documents at each major OS, hardware, or office software
upgrade. Before decommissioning the last instance of the old system,
load and read a few sample documents on the new system. If there is a
problem, use the old system to convert to an updated format.

On 6/10/2016 7:29 AM, Damjan Jovanovic wrote:

Hi Roger

If you saved them in OpenOffice's default format, OpenDocument (.odt /
.ods
/ .odb etc.), then yes. Password protection is part of the OpenDocument
standard, and should be supported by us and other OpenDocument software
such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The
encryption techniques are all well documented and use common well
established ciphers, hash functions and password strengthening procedures.

With long term storage, the problem won't be data becoming inaccessible
due
to encryption (provided you remember your passwords), so much as the
opposite problem, of data becoming too easily accessible, since older
versions of OpenDocument used weaker encryption ciphers, potentially
making
document encryption too easy to crack by future weaknesses discovered in
those ciphers and with more powerful computers in the future.

Regards
Damjan

On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley 
wrote:


Dear Sir/Madam

I have a large number of important documents that I have created over the
years in Open Office, which were created as password protected documents.

Is there any likelihood in the future of any ‘redundancy’ or suchlike
where these documents would be no longer accessible by future then
current
software etc?  Or will the files always remain safe, in that there will
always be an Open Office allied program capable of unlocking their
password
protected format?

I will be very grateful of your reply.

With sincere regards

Roger Bentley




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A Question about Open Office Password Protected Text Documents

2016-06-10 Thread Roger Bentley 

Dear Mr Jovanovic

Thank you very much for your email.

Your reply is greatly appreciated.

Thank you.

With sincere regards

Roger Bentley


-Original Message- 
From: Damjan Jovanovic

Sent: Friday, June 10, 2016 3:29 PM
To: Apache OO
Subject: Re: A Question about Open Office Password Protected Text Documenets

Hi Roger

If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods
/ .odb etc.), then yes. Password protection is part of the OpenDocument
standard, and should be supported by us and other OpenDocument software
such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The
encryption techniques are all well documented and use common well
established ciphers, hash functions and password strengthening procedures.

With long term storage, the problem won't be data becoming inaccessible due
to encryption (provided you remember your passwords), so much as the
opposite problem, of data becoming too easily accessible, since older
versions of OpenDocument used weaker encryption ciphers, potentially making
document encryption too easy to crack by future weaknesses discovered in
those ciphers and with more powerful computers in the future.

Regards
Damjan

On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley 
wrote:


Dear Sir/Madam

I have a large number of important documents that I have created over the
years in Open Office, which were created as password protected documents.

Is there any likelihood in the future of any ‘redundancy’ or suchlike
where these documents would be no longer accessible by future then current
software etc?  Or will the files always remain safe, in that there will
always be an Open Office allied program capable of unlocking their 
password

protected format?

I will be very grateful of your reply.

With sincere regards

Roger Bentley 



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: A Question about Open Office Password Protected Text Documenets

2016-06-10 Thread Dennis E. Hamilton 


> -Original Message-
> From: toki [mailto:toki.kant...@gmail.com]
> Sent: Friday, June 10, 2016 11:49
> To: dev@openoffice.apache.org
> Subject: RE: A Question about Open Office Password Protected Text
> Documenets
[ ... ]
> #
> 
> From a security perspective, the password protection offered by
> LibreOffice, Apache Open Office, etc, is roughly equivalent to closing
> the door and windows of a house.
> 
> jonathon
> 
[orcmid] 

Well-said.  

 - Dennis
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: A Question about Open Office Password Protected Text Documenets

2016-06-10 Thread Dennis E. Hamilton 
I forgot something important.

By default, Apache OpenOffice, as recently as AOO 4.1.2, does *not* use any 
encryption methods other than those that have been used since ODF 1.0 in 2005.  
So statements about more-advanced methods do not apply for AOO.

I believe AOO will accept (some of) the additional parameters defined for 
encrypted documents with ODF 1.2, but AOO does not produce such encryptions on 
documents saved-with-password.

 - Dennis

CONFIRMATION

I created a simple saved-with-password .odt using AOO 4.1.2 Writer.  My options 
for this were with

  Tools > Options > Load/Save > General > ODF format version > 1.2 extended 
(recommended).

When I specified Save with Password, there are no options to choose anything 
with regard to how that is done.

When I inspected the .odt via Zip, the manifest.xml reveals the following about 
encryption of the first file in the manifest:


   
  





This is the default approach since ODF 1.0.  

I was able to open this document in both AOO 4.1.2 (with the password I 
created), and also in LibreOffice 5.0.0.  I resaved the document from 
LibreOffice into a new file, reusing the same password.  I was able to open 
that document in AOO 4.1.2 with that password too.

The LibreOffice 5.0.0 encryption is different.  Here is how the manifest.xml in 
the LibreOffice saved file reports the encryption parameters for the same 
document part as above:


   
  http://www.w3.org/2001/04/xmlenc#aes256-cbc; 
   manifest:initialisation-vector="6b3kaGTPf2NojfuqUuWB0Q=="/>
  
  http://www.w3.org/2000/09/xmldsig#sha256; 
   manifest:key-size="32"/>



The differences are mainly use of SHA256 instead of SHA1 and the use of AES256 
instead of Blowfish.

The most-vulnerable aspects are the manifest:key-derivation technique and the 
manifest:start-key-generation.  The manifest:iteration-count of 1024 is 
negligible.  Oh, and the unencrypted stream, 
Configurations2/accelerator/current.xml, is completely known already.




> -Original Message-
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Friday, June 10, 2016 10:55
> To: dev@openoffice.apache.org
> Subject: RE: A Question about Open Office Password Protected Text
> Documenets
> 
> 
> 
> > -Original Message-
> > From: Damjan Jovanovic [mailto:dam...@apache.org]
> > Sent: Friday, June 10, 2016 07:29
> > To: Apache OO 
> > Subject: Re: A Question about Open Office Password Protected Text
> > Documenets
> >
> > Hi Roger
> >
> > If you saved them in OpenOffice's default format, OpenDocument (.odt /
> > .ods
> > / .odb etc.), then yes. Password protection is part of the
> OpenDocument
> > standard, and should be supported by us and other OpenDocument
> software
> > such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The
> > encryption techniques are all well documented and use common well
> > established ciphers, hash functions and password strengthening
> > procedures.
> >
> > With long term storage, the problem won't be data becoming
> inaccessible
> > due
> > to encryption (provided you remember your passwords), so much as the
> > opposite problem, of data becoming too easily accessible, since older
> > versions of OpenDocument used weaker encryption ciphers, potentially
> > making
> > document encryption too easy to crack by future weaknesses discovered
> in
> > those ciphers and with more powerful computers in the future.
> [orcmid]
> 
> There is a misunderstanding here.  The problem of using the latest-and-
> greatest (i.e, based on AES) supported encryptions is that older
> versions of software won't be able to open it and versions that have not
> upgraded their support or for which there is an interoperability defect
> won't open it either.
> 
> We ran into this recently where users of Mac OSX could no longer open
> some password-protected files.
> 
> It is not in our power to offer a guarantee about this.  At the moment,
> the basic cryptography used since ODF 1.0 is working.  There is no way
> that the project can assert that this will apply in perpetuity and that
> software to accomplish it will always be available.  That is beyond our
> means.
> 
> Finally, the use of better hash algorithms and AES as a check-box item
> do *not* eliminate the known exposure of ODF documents to cryptographic
> attack and decryption by an adversary.  ODF encryption should *never* be
> used for highly-confidential documents, especially files subject to
> security-classification regimes of governments or other entities.  I
> don't belief any such agency would permit ODF encryption to be used;
> encryption would be accomplished by other means.
> 
> The reasons for that are quite simple:
> 
>  1. All ODF encryption is password-based.  That is the greatest single
> vulnerability, especially if the same password is used on multiple
> documents.  There

RE: A Question about Open Office Password Protected Text Documenets

2016-06-10 Thread toki 
Roger wrote:

>Is there any likelihood in the future of any ‘redundancy’ or suchlike where 
>these documents would be no longer accessible by future then current software 
>etc? 

The presence or absence of a specific feature or function being on the
roadmap, does not preclude it from being in a future version of the program.

Ideally, there will at least one version of a future program that can
read/write passwords created by the current algorithm, and by the
proposed/future password algorithm.

>in that there will always be an Open Office allied program capable of 
>unlocking their password protected format?

In as much as there is off the shelf software, that is not related to
OpenOffice.org, that can read/write passwords created using either the
current algorithm, and the former algorithm, I'm fairly confident that
any future algorithm changes to password creation, will be incorporated
into that off the shelf non-OOo related software. {That the software is
available, does not mean that it will display the password, within a
human lifetime.}

#

>From a security perspective, the password protection offered by
LibreOffice, Apache Open Office, etc, is roughly equivalent to closing
the door and windows of a house.

jonathon

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: A Question about Open Office Password Protected Text Documenets

2016-06-10 Thread Dennis E. Hamilton 


> -Original Message-
> From: Damjan Jovanovic [mailto:dam...@apache.org]
> Sent: Friday, June 10, 2016 07:29
> To: Apache OO 
> Subject: Re: A Question about Open Office Password Protected Text
> Documenets
> 
> Hi Roger
> 
> If you saved them in OpenOffice's default format, OpenDocument (.odt /
> .ods
> / .odb etc.), then yes. Password protection is part of the OpenDocument
> standard, and should be supported by us and other OpenDocument software
> such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The
> encryption techniques are all well documented and use common well
> established ciphers, hash functions and password strengthening
> procedures.
> 
> With long term storage, the problem won't be data becoming inaccessible
> due
> to encryption (provided you remember your passwords), so much as the
> opposite problem, of data becoming too easily accessible, since older
> versions of OpenDocument used weaker encryption ciphers, potentially
> making
> document encryption too easy to crack by future weaknesses discovered in
> those ciphers and with more powerful computers in the future.
[orcmid] 

There is a misunderstanding here.  The problem of using the latest-and-greatest 
(i.e, based on AES) supported encryptions is that older versions of software 
won't be able to open it and versions that have not upgraded their support or 
for which there is an interoperability defect won't open it either.

We ran into this recently where users of Mac OSX could no longer open some 
password-protected files. 

It is not in our power to offer a guarantee about this.  At the moment, the 
basic cryptography used since ODF 1.0 is working.  There is no way that the 
project can assert that this will apply in perpetuity and that software to 
accomplish it will always be available.  That is beyond our means.

Finally, the use of better hash algorithms and AES as a check-box item do *not* 
eliminate the known exposure of ODF documents to cryptographic attack and 
decryption by an adversary.  ODF encryption should *never* be used for 
highly-confidential documents, especially files subject to 
security-classification regimes of governments or other entities.  I don't 
belief any such agency would permit ODF encryption to be used; encryption would 
be accomplished by other means. 

The reasons for that are quite simple:

 1. All ODF encryption is password-based.  That is the greatest single 
vulnerability, especially if the same password is used on multiple documents.  
There are extremely well-known and highly-available means for attacking 
encryptions using memorable passwords.  This vulnerability trumps everything.  
This is something the software does not control and cannot mitigate much.  Note 
that advertised password-recovery software *does* succeed against 
password-protected ODF documents on occasion.  The advances in computer 
performance (especially graphics processors) ensure that the number of 
passwords that are defeated by such software will only increase.

 2. Because the encryption is of a static, persistent document, the attack can 
be conducted off-line for a sustained time and using coordinated crowd-sourced 
attacks.  Advances in technology have neutralized the measures used to make 
attacking of the password computationally difficult.  This means that documents 
retaining long-duration secrets are the most vulnerable if not adequately 
protected against disclosure.

 3. The particular encryption approach (not the low-level choice of the 
stream-level encryption algorithm) leaks information about the original ODF 
document to the point where some unencrypted information may be determined by 
means other than actually having to decrypt it.  That revelation can be used to 
expedite attack on the password used for the unknown parts.

As a final thought.  It is revealing that Microsoft Office will not produce ODF 
documents that are saved with a password, although it will otherwise support 
ODF format.  In addition, the software refuses to open such documents, although 
it certainly could go that far, in principle.  So there is no means to rescue 
password-saved ODF documents in the most widely-available ODF-supporting 
software on the planet.

 - Dennis
> 
> Regards
> Damjan
> 
> On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley
> 
> wrote:
> 
> > Dear Sir/Madam
> >
> > I have a large number of important documents that I have created over
> the
> > years in Open Office, which were created as password protected
> documents.
> >
> > Is there any likelihood in the future of any ‘redundancy’ or suchlike
> > where these documents would be no longer accessible by future then
> current
> > software etc?  Or will the files always remain safe, in that there
> will
> > always be an Open Office allied program capable of unlocking their
> password
> > protected format?
> >
> > I will be very grateful of your reply.
> >
> > With sincere regards
>

Re: failed to build aoo420 dev on win32

2016-06-10 Thread Damjan Jovanovic 
The "assertion failed" messageboxes problem (#i126918#) is fixed in trunk
now. You no longer need --disable-unit-tests, and are better off with the
unit tests enabled.

Regards
Damjan

On Sun, Apr 10, 2016 at 2:28 PM, Oliver Brinzing 
wrote:

> Hi Patricia,
>
> thanks for your build settings.
> Did you manage to build  aoo420 debug version?
>
> yesterday i started a new aoo412 debug build with my settings.
> after 5 hours the build finished without any problems.
>
> i tried again with rev 1738357 and failed again... added 4 issues:
>
> windows build breaks in module crashrep - Assertion Failed
> https://bz.apache.org/ooo/show_bug.cgi?id=126918
>
> windows build breaks in module connectivity/source/parse/sqliterator.cxx
> https://bz.apache.org/ooo/show_bug.cgi?id=126917
>
> windows build breaks in module formula
> https://bz.apache.org/ooo/show_bug.cgi?id=126916
>
> windows build breaks in module sc/source/filter/excel - missing #include
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=126919
>
> maybe i should try again with " --disable-pch" do not use multiple
> parallel processes feature (e.g. build --all -P2 -- -P2)
>
> Regards
> Oliver
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: A Question about Open Office Password Protected Text Documenets

2016-06-10 Thread Patricia Shanahan 
That said, if I had a set of business-critical documents, I would test 
some sample documents at each major OS, hardware, or office software 
upgrade. Before decommissioning the last instance of the old system, 
load and read a few sample documents on the new system. If there is a 
problem, use the old system to convert to an updated format.


On 6/10/2016 7:29 AM, Damjan Jovanovic wrote:

Hi Roger

If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods
/ .odb etc.), then yes. Password protection is part of the OpenDocument
standard, and should be supported by us and other OpenDocument software
such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The
encryption techniques are all well documented and use common well
established ciphers, hash functions and password strengthening procedures.

With long term storage, the problem won't be data becoming inaccessible due
to encryption (provided you remember your passwords), so much as the
opposite problem, of data becoming too easily accessible, since older
versions of OpenDocument used weaker encryption ciphers, potentially making
document encryption too easy to crack by future weaknesses discovered in
those ciphers and with more powerful computers in the future.

Regards
Damjan

On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley 
wrote:


Dear Sir/Madam

I have a large number of important documents that I have created over the
years in Open Office, which were created as password protected documents.

Is there any likelihood in the future of any ‘redundancy’ or suchlike
where these documents would be no longer accessible by future then current
software etc?  Or will the files always remain safe, in that there will
always be an Open Office allied program capable of unlocking their password
protected format?

I will be very grateful of your reply.

With sincere regards

Roger Bentley




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org