AOOo can't save passwort protected file
Hi all Can sameone confirm the flowing on a AOOo Build? Steps to reproduce - Open a new Writer Document - Write same text - Save as - check password protection and choice a name - press enter and give in a passwort and confirm it Result: I get a error that the document can't be saved. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
RE: AOOo can't save passwort protected file
I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 to see if the problem existed previously. I was able to password protect (encrypt) a simple Writer document. It saved and opened fine (after I gave the password again. What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to open the document and never got to recognizing that it was encrypted. I got a bad XML message, suggesting that an encrypted file was being mistakenly opened without decryption first. I haven't looked at the package yet to see what is unusual. It is in my queue of documents awaiting forensic analysis. - Dennis -Original Message- From: Raphael Bircher [mailto:r.birc...@gmx.ch] Sent: Thursday, September 15, 2011 15:18 To: ooo-dev@incubator.apache.org Subject: AOOo can't save passwort protected file Hi all Can sameone confirm the flowing on a AOOo Build? Steps to reproduce - Open a new Writer Document - Write same text - Save as - check password protection and choice a name - press enter and give in a passwort and confirm it Result: I get a error that the document can't be saved. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
hi, Raphael I built out AOOo on my Ubuntu 11 days ago. Just now, I tried the steps you described. The results are that : 1) There will be a general IO error, when saving the document with password to ODT format. Please refer to the snapshot attached. 2) If change to DOC format, there is no such issue. I also tried LibreOffice on Ubuntu. There is no such issue for ODT. So I think that it is easy to fix the defect in AOOo. On Fri, 2011-09-16 at 00:17 +0200, Raphael Bircher wrote: > Hi all > > Can sameone confirm the flowing on a AOOo Build? > > Steps to reproduce > > - Open a new Writer Document > - Write same text > - Save as > - check password protection and choice a name > - press enter and give in a passwort and confirm it > > Result: > I get a error that the document can't be saved. > > Greetings Raphael -- Chao Huang
Re: AOOo can't save passwort protected file
Hi Dennis Thank you for the test too Am 16.09.11 03:19, schrieb Dennis E. Hamilton: I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 to see if the problem existed previously. I was able to password protect (encrypt) a simple Writer document. It saved and opened fine (after I gave the password again. So this is maybe a regression What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to open the document and never got to recognizing that it was encrypted. I got a bad XML message, suggesting that an encrypted file was being mistakenly opened without decryption first. I think, that has nothing to do with it. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
Hi Raphael, i assume you have built your office with at least --disable-mozilla, correct? As far as i know the password encryption used some stuff from the mozilla code. So there will be a problem. Juergen On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: > Hi Dennis > > Thank you for the test too > > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: > > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >> win32 to see if the problem existed previously. I was able to password >> protect (encrypt) a simple Writer document. It saved and opened fine (after >> I gave the password again. >> > So this is maybe a regression > > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> open the document and never got to recognizing that it was encrypted. I got >> a bad XML message, suggesting that an encrypted file was being mistakenly >> opened without decryption first. >> > I think, that has nothing to do with it. > > > Greetings Raphael > > > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: AOOo can't save passwort protected file
hi, Jürgen Yes, I built AOOo with argument "--disable-mozilla". I will try to rebuild AOOo without that arg. Do we have any alternative way to solve the problem quickly? For example, put mozilla library into someplace? Thanks! On Fri, 2011-09-16 at 10:30 +0200, Jürgen Schmidt wrote: > Hi Raphael, > > i assume you have built your office with at least --disable-mozilla, > correct? As far as i know the password encryption used some stuff from the > mozilla code. So there will be a problem. > > Juergen > > > On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: > > > Hi Dennis > > > > Thank you for the test too > > > > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: > > > > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on > >> win32 to see if the problem existed previously. I was able to password > >> protect (encrypt) a simple Writer document. It saved and opened fine > >> (after > >> I gave the password again. > >> > > So this is maybe a regression > > > > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to > >> open the document and never got to recognizing that it was encrypted. I > >> got > >> a bad XML message, suggesting that an encrypted file was being mistakenly > >> opened without decryption first. > >> > > I think, that has nothing to do with it. > > > > > > Greetings Raphael > > > > > > -- > > My private Homepage: http://www.raphaelbircher.ch/ > > -- Chao Huang
Re: AOOo can't save passwort protected file
Hi Jürgen Exactly, I used --disable-copyleft wich automaticly use --disable-mozilla. Thanks, for your information. I assume that this has samething to do with the copyleft removal. Greetings Raphael Am 16.09.11 10:30, schrieb Jürgen Schmidt: Hi Raphael, i assume you have built your office with at least --disable-mozilla, correct? As far as i know the password encryption used some stuff from the mozilla code. So there will be a problem. Juergen On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: Hi Dennis Thank you for the test too Am 16.09.11 03:19, schrieb Dennis E. Hamilton: I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 to see if the problem existed previously. I was able to password protect (encrypt) a simple Writer document. It saved and opened fine (after I gave the password again. So this is maybe a regression What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to open the document and never got to recognizing that it was encrypted. I got a bad XML message, suggesting that an encrypted file was being mistakenly opened without decryption first. I think, that has nothing to do with it. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/ -- My private Homepage: http://www.raphaelbircher.ch/
RE: AOOo can't save passwort protected file
I agree that the OO.o 2.4.1 being unable to open the document is not this problem. It is an indication that something is occurring in the OOo-dev 3.4 package that breaks down-level compatibility for no apparent reason, and a separate issue (not yet investigated). I FOUND IT: Beside using manifest:version="1.2", OOO-dev 3.4 uses aes256-cbc as the encryption algorithm. That is going to fail in any down-level implementation that does not support this allowed but not default encryption. SUGGESTED TEST: To see if the Save As with Password problem is related to choice of encryption method (and what may or may not be in the build), I suggest trying the Save As with Password after changing Tools | Options | Load/Save | General | ODF format version from 1.2 Extended to 1.2, and if that still fails, try ODF format 1.0/1.1 also. (I can't run that build, or I would do this myself.) -Original Message- From: Raphael Bircher [mailto:r.birc...@gmx.ch] Sent: Friday, September 16, 2011 01:01 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file Hi Dennis Thank you for the test too Am 16.09.11 03:19, schrieb Dennis E. Hamilton: > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 > to see if the problem existed previously. I was able to password protect > (encrypt) a simple Writer document. It saved and opened fine (after I gave > the password again. So this is maybe a regression > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to > open the document and never got to recognizing that it was encrypted. I got > a bad XML message, suggesting that an encrypted file was being mistakenly > opened without decryption first. I think, that has nothing to do with it. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
On Fri, Sep 16, 2011 at 1:24 PM, Dennis E. Hamilton wrote: > I agree that the OO.o 2.4.1 being unable to open the document is not this > problem. > Is that a typo? Or are you really debugging this with an OOo 2.4.1 release from 2008? > It is an indication that something is occurring in the OOo-dev 3.4 package > that breaks down-level compatibility for no apparent reason, and a separate > issue (not yet investigated). > > I FOUND IT: Beside using manifest:version="1.2", > OOO-dev 3.4 uses aes256-cbc as the encryption algorithm. That is going to > fail in any down-level implementation that does not support this allowed but > not default encryption. > > SUGGESTED TEST: > > To see if the Save As with Password problem is related to choice of > encryption method (and what may or may not be in the build), I suggest trying > the Save As with Password after changing Tools | Options | Load/Save | > General | ODF format version from 1.2 Extended to 1.2, > and if that still fails, try ODF format 1.0/1.1 also. > > (I can't run that build, or I would do this myself.) > > -Original Message- > From: Raphael Bircher [mailto:r.birc...@gmx.ch] > Sent: Friday, September 16, 2011 01:01 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > Hi Dennis > > Thank you for the test too > > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >> I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 >> to see if the problem existed previously. I was able to password protect >> (encrypt) a simple Writer document. It saved and opened fine (after I gave >> the password again. > So this is maybe a regression >> What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> open the document and never got to recognizing that it was encrypted. I got >> a bad XML message, suggesting that an encrypted file was being mistakenly >> opened without decryption first. > I think, that has nothing to do with it. > > Greetings Raphael > > > -- > My private Homepage: http://www.raphaelbircher.ch/ > >
RE: AOOo can't save passwort protected file
Oh, there is another bug in Save As with Password. You can't turn it off in saving the opened encrypted document to a new file with the Password checkbox cleared. It saves the document with password anyhow and has automatically reused the same password (very naughty). [Now I know where LibreOffice got this bug.] Just for the record. I must do some bugzilla issues after brunch. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Friday, September 16, 2011 10:25 To: 'ooo-dev@incubator.apache.org' Subject: RE: AOOo can't save passwort protected file I agree that the OO.o 2.4.1 being unable to open the document is not this problem. It is an indication that something is occurring in the OOo-dev 3.4 package that breaks down-level compatibility for no apparent reason, and a separate issue (not yet investigated). I FOUND IT: Beside using manifest:version="1.2", OOO-dev 3.4 uses aes256-cbc as the encryption algorithm. That is going to fail in any down-level implementation that does not support this allowed but not default encryption. SUGGESTED TEST: To see if the Save As with Password problem is related to choice of encryption method (and what may or may not be in the build), I suggest trying the Save As with Password after changing Tools | Options | Load/Save | General | ODF format version from 1.2 Extended to 1.2, and if that still fails, try ODF format 1.0/1.1 also. (I can't run that build, or I would do this myself.) -Original Message- From: Raphael Bircher [mailto:r.birc...@gmx.ch] Sent: Friday, September 16, 2011 01:01 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file Hi Dennis Thank you for the test too Am 16.09.11 03:19, schrieb Dennis E. Hamilton: > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 > to see if the problem existed previously. I was able to password protect > (encrypt) a simple Writer document. It saved and opened fine (after I gave > the password again. So this is maybe a regression > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to > open the document and never got to recognizing that it was encrypted. I got > a bad XML message, suggesting that an encrypted file was being mistakenly > opened without decryption first. I think, that has nothing to do with it. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
RE: AOOo can't save passwort protected file
I use a series of older versions as part of my document forensics work. In particular, I keep ODF 1.1 processors around. It happened that it is the default application in the same VM where I have OOo-dev 3.4 installed. So it opened by accident on a double-click where I was testing for the Save As with Password problem, to see if it existed in OOo-dev 3.4. So I found a down-level regression by happy accident. And that had me learn that the OOo-dev 3.4 uses AES encryption by default, which no ODF 1.0/1.1 client will recognize, nor will many ODF 1.2 apps not built to recognize anything more than the default encryption (there being no requirement that they do otherwise). To confirm how much down-version breakage there might be I tried these: LibreOffice 3.4.2 fails on the document in exactly the same way that OO.o 2.4.1 does. So does Lotus Symphony 3.0.0 FP3. So maybe the first Apache OO.o release should not switch from the default encryption algorithm so hastily. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Friday, September 16, 2011 10:30 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file On Fri, Sep 16, 2011 at 1:24 PM, Dennis E. Hamilton wrote: > I agree that the OO.o 2.4.1 being unable to open the document is not this > problem. > Is that a typo? Or are you really debugging this with an OOo 2.4.1 release from 2008? > It is an indication that something is occurring in the OOo-dev 3.4 package > that breaks down-level compatibility for no apparent reason, and a separate > issue (not yet investigated). > > I FOUND IT: Beside using manifest:version="1.2", > OOO-dev 3.4 uses aes256-cbc as the encryption algorithm. That is going to > fail in any down-level implementation that does not support this allowed but > not default encryption. > > SUGGESTED TEST: > > To see if the Save As with Password problem is related to choice of > encryption method (and what may or may not be in the build), I suggest trying > the Save As with Password after changing Tools | Options | Load/Save | > General | ODF format version from 1.2 Extended to 1.2, > and if that still fails, try ODF format 1.0/1.1 also. > > (I can't run that build, or I would do this myself.) > > -Original Message- > From: Raphael Bircher [mailto:r.birc...@gmx.ch] > Sent: Friday, September 16, 2011 01:01 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > Hi Dennis > > Thank you for the test too > > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >> I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on win32 >> to see if the problem existed previously. I was able to password protect >> (encrypt) a simple Writer document. It saved and opened fine (after I gave >> the password again. > So this is maybe a regression >> What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> open the document and never got to recognizing that it was encrypted. I got >> a bad XML message, suggesting that an encrypted file was being mistakenly >> opened without decryption first. > I think, that has nothing to do with it. > > Greetings Raphael > > > -- > My private Homepage: http://www.raphaelbircher.ch/ > >
Re: AOOo can't save passwort protected file
On Fri, Sep 16, 2011 at 1:47 PM, Dennis E. Hamilton wrote: > I use a series of older versions as part of my document forensics work. In > particular, I keep ODF 1.1 processors around. > > It happened that it is the default application in the same VM where I have > OOo-dev 3.4 installed. So it opened by accident on a double-click where I > was testing for the Save As with Password problem, to see if it existed in > OOo-dev 3.4. > > So I found a down-level regression by happy accident. And that had me learn > that the OOo-dev 3.4 uses AES encryption by default, which no ODF 1.0/1.1 > client will recognize, nor will many ODF 1.2 apps not built to recognize > anything more than the default encryption (there being no requirement that > they do otherwise). > So none of this is relevant to the issue that Raphael reported. The issue reported was inability to *save* a document with a password. If you have a different issue related to reading 3.4 documents in OOo 2.4 you should probably entered that into BZ, so we don't lose track of it. > To confirm how much down-version breakage there might be I tried these: > > LibreOffice 3.4.2 fails on the document in exactly the same way that OO.o > 2.4.1 does. > > So does Lotus Symphony 3.0.0 FP3. > > So maybe the first Apache OO.o release should not switch from the default > encryption algorithm so hastily. > > - Dennis > > > > -Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Friday, September 16, 2011 10:30 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > On Fri, Sep 16, 2011 at 1:24 PM, Dennis E. Hamilton > wrote: >> I agree that the OO.o 2.4.1 being unable to open the document is not this >> problem. >> > > Is that a typo? Or are you really debugging this with an OOo 2.4.1 > release from 2008? > >> It is an indication that something is occurring in the OOo-dev 3.4 package >> that breaks down-level compatibility for no apparent reason, and a separate >> issue (not yet investigated). >> >> I FOUND IT: Beside using manifest:version="1.2", >> OOO-dev 3.4 uses aes256-cbc as the encryption algorithm. That is going to >> fail in any down-level implementation that does not support this allowed but >> not default encryption. >> >> SUGGESTED TEST: >> >> To see if the Save As with Password problem is related to choice of >> encryption method (and what may or may not be in the build), I suggest >> trying the Save As with Password after changing Tools | Options | Load/Save >> | General | ODF format version from 1.2 Extended to 1.2, >> and if that still fails, try ODF format 1.0/1.1 also. >> >> (I can't run that build, or I would do this myself.) >> >> -Original Message- >> From: Raphael Bircher [mailto:r.birc...@gmx.ch] >> Sent: Friday, September 16, 2011 01:01 >> To: ooo-dev@incubator.apache.org >> Subject: Re: AOOo can't save passwort protected file >> >> Hi Dennis >> >> Thank you for the test too >> >> Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >>> I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >>> win32 to see if the problem existed previously. I was able to password >>> protect (encrypt) a simple Writer document. It saved and opened fine >>> (after I gave the password again. >> So this is maybe a regression >>> What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >>> open the document and never got to recognizing that it was encrypted. I >>> got a bad XML message, suggesting that an encrypted file was being >>> mistakenly opened without decryption first. >> I think, that has nothing to do with it. >> >> Greetings Raphael >> >> >> -- >> My private Homepage: http://www.raphaelbircher.ch/ >> >> > >
Re: AOOo can't save passwort protected file
Hi Dennis Am 16.09.11 19:47, schrieb Dennis E. Hamilton: I use a series of older versions as part of my document forensics work. In particular, I keep ODF 1.1 processors around. It happened that it is the default application in the same VM where I have OOo-dev 3.4 installed. So it opened by accident on a double-click where I was testing for the Save As with Password problem, to see if it existed in OOo-dev 3.4. So I found a down-level regression by happy accident. And that had me learn that the OOo-dev 3.4 uses AES encryption by default, which no ODF 1.0/1.1 client will recognize, nor will many ODF 1.2 apps not built to recognize anything more than the default encryption (there being no requirement that they do otherwise). You can switch the ODF Version under Tools > Options > Load/Save. Please try to switch from ODF 1.2 extended to 1.2 or maybe 1.0/1.1 and test to open it with the 2.4 again. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
RE: AOOo can't save passwort protected file
Yes, Raphael, I know to do that concerning the AES issue. My suggestion (in the part of the message that you clipped) is that the same thing be done with the new AOOo build to see if the crash is dependent on the default use of AES in that build or if any mode of Save As ... with Password causes the Save to fail. I have now identified two defects to add to the AOOo bugzilla that are separate from the Save failure. - Dennis -Original Message- From: Raphael Bircher [mailto:r.birc...@gmx.ch] Sent: Friday, September 16, 2011 12:05 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file Hi Dennis Am 16.09.11 19:47, schrieb Dennis E. Hamilton: > I use a series of older versions as part of my document forensics work. In > particular, I keep ODF 1.1 processors around. > > It happened that it is the default application in the same VM where I have > OOo-dev 3.4 installed. So it opened by accident on a double-click where I > was testing for the Save As with Password problem, to see if it existed in > OOo-dev 3.4. > > So I found a down-level regression by happy accident. And that had me learn > that the OOo-dev 3.4 uses AES encryption by default, which no ODF 1.0/1.1 > client will recognize, nor will many ODF 1.2 apps not built to recognize > anything more than the default encryption (there being no requirement that > they do otherwise). You can switch the ODF Version under Tools > Options > Load/Save. Please try to switch from ODF 1.2 extended to 1.2 or maybe 1.0/1.1 and test to open it with the 2.4 again. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
Hi, AOOo can't use the nss libraries as easily as it was possible in the "old" OOo, so perhaps a fix would be to revert the default encryption algorithm in AOOo from AES to Blowfish in 3.4 until we found a replacement for the AES encryption code from the nss libs. I know that MPL libs can be used "in binary form" in Apache projects, here's the wording: "Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled: (...)" (lists MPL 1.0 and 1.1) As most 3rd party software is included in binary form in release anyway, I wonder what that means in practice. Perhaps somebody in the know can explain that. Regards, Mathias Am 16.09.2011 10:40, schrieb Chao Huang: > hi, Jürgen > > Yes, I built AOOo with argument "--disable-mozilla". I will try to > rebuild AOOo without that arg. > > Do we have any alternative way to solve the problem quickly? For > example, put mozilla library into someplace? Thanks! > > > On Fri, 2011-09-16 at 10:30 +0200, Jürgen Schmidt wrote: >> Hi Raphael, >> >> i assume you have built your office with at least --disable-mozilla, >> correct? As far as i know the password encryption used some stuff from the >> mozilla code. So there will be a problem. >> >> Juergen >> >> >> On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: >> >> > Hi Dennis >> > >> > Thank you for the test too >> > >> > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >> > >> > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >> >> win32 to see if the problem existed previously. I was able to password >> >> protect (encrypt) a simple Writer document. It saved and opened fine >> >> (after >> >> I gave the password again. >> >> >> > So this is maybe a regression >> > >> > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> >> open the document and never got to recognizing that it was encrypted. I >> >> got >> >> a bad XML message, suggesting that an encrypted file was being mistakenly >> >> opened without decryption first. >> >> >> > I think, that has nothing to do with it. >> > >> > >> > Greetings Raphael >> > >> > >> > -- >> > My private Homepage: http://www.raphaelbircher.ch/ >> > >
RE: AOOo can't save passwort protected file
I think reverting to Blowfish with 8-bit CFB and the default algorithms is a good idea regardless. I have confirmed that when OOo-dev 3.4 is set to save in ODF 1.0/1.1 format, it will use the default algorithms for Password protection of files, as expected. I also confirmed that saving in ODF 1.2 and ODF 1.2 extended format, the aes256 algorithm is used. The resulting encrypted document will fail on open with any of these releases: OpenOffice.org 2.4.1 OpenOffice.org 3.2.0 LibreOffice.org 3.3.2 LibreOffice.org 3.4.3 Lotus Symphony 3 fixpack3 Note that the only algorithm required to be supported by ODF 1.2 Package consumers is the default Blowfish CFB. Other algorithms are admissible, but none are recommended in the ODF 1.2 specification and only the one is required. - Dennis -Original Message- From: Mathias Bauer [mailto:mathias_ba...@gmx.net] Sent: Friday, September 16, 2011 15:40 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file Hi, AOOo can't use the nss libraries as easily as it was possible in the "old" OOo, so perhaps a fix would be to revert the default encryption algorithm in AOOo from AES to Blowfish in 3.4 until we found a replacement for the AES encryption code from the nss libs. I know that MPL libs can be used "in binary form" in Apache projects, here's the wording: "Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled: (...)" (lists MPL 1.0 and 1.1) As most 3rd party software is included in binary form in release anyway, I wonder what that means in practice. Perhaps somebody in the know can explain that. Regards, Mathias Am 16.09.2011 10:40, schrieb Chao Huang: > hi, Jürgen > > Yes, I built AOOo with argument "--disable-mozilla". I will try to > rebuild AOOo without that arg. > > Do we have any alternative way to solve the problem quickly? For > example, put mozilla library into someplace? Thanks! > > > On Fri, 2011-09-16 at 10:30 +0200, Jürgen Schmidt wrote: >> Hi Raphael, >> >> i assume you have built your office with at least --disable-mozilla, >> correct? As far as i know the password encryption used some stuff from the >> mozilla code. So there will be a problem. >> >> Juergen >> >> >> On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: >> >> > Hi Dennis >> > >> > Thank you for the test too >> > >> > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: >> > >> > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >> >> win32 to see if the problem existed previously. I was able to password >> >> protect (encrypt) a simple Writer document. It saved and opened fine >> >> (after >> >> I gave the password again. >> >> >> > So this is maybe a regression >> > >> > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> >> open the document and never got to recognizing that it was encrypted. I >> >> got >> >> a bad XML message, suggesting that an encrypted file was being mistakenly >> >> opened without decryption first. >> >> >> > I think, that has nothing to do with it. >> > >> > >> > Greetings Raphael >> > >> > >> > -- >> > My private Homepage: http://www.raphaelbircher.ch/ >> > >
RE: AOOo can't save passwort protected file
Raphael, When you set Writer to Save as ODF 1.0/1.1, does it work then? -Original Message- From: Raphael Bircher [mailto:r.birc...@gmx.ch] Sent: Thursday, September 15, 2011 15:18 To: ooo-dev@incubator.apache.org Subject: AOOo can't save passwort protected file Hi all Can sameone confirm the flowing on a AOOo Build? Steps to reproduce - Open a new Writer Document - Write same text - Save as - check password protection and choice a name - press enter and give in a passwort and confirm it Result: I get a error that the document can't be saved. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
Hi Dennis Am 17.09.11 01:51, schrieb Dennis E. Hamilton: Raphael, When you set Writer to Save as ODF 1.0/1.1, does it work then? Good idea, but it dosn't help Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: AOOo can't save passwort protected file
+1 to reverting to Blowfish for now. Also note that we can use BouncyCastle in the future if using java for this is acceptable. Pedro. On Sat, 17 Sep 2011 00:39:31 +0200, Mathias Bauer wrote: Hi, AOOo can't use the nss libraries as easily as it was possible in the "old" OOo, so perhaps a fix would be to revert the default encryption algorithm in AOOo from AES to Blowfish in 3.4 until we found a replacement for the AES encryption code from the nss libs. I know that MPL libs can be used "in binary form" in Apache projects, here's the wording: "Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled: (...)" (lists MPL 1.0 and 1.1) As most 3rd party software is included in binary form in release anyway, I wonder what that means in practice. Perhaps somebody in the know can explain that. Regards, Mathias Am 16.09.2011 10:40, schrieb Chao Huang: hi, Jürgen Yes, I built AOOo with argument "--disable-mozilla". I will try to rebuild AOOo without that arg. Do we have any alternative way to solve the problem quickly? For example, put mozilla library into someplace? Thanks! On Fri, 2011-09-16 at 10:30 +0200, Jürgen Schmidt wrote: Hi Raphael, i assume you have built your office with at least --disable-mozilla, correct? As far as i know the password encryption used some stuff from the mozilla code. So there will be a problem. Juergen On Fri, Sep 16, 2011 at 10:01 AM, Raphael Bircher wrote: > Hi Dennis > > Thank you for the test too > > Am 16.09.11 03:19, schrieb Dennis E. Hamilton: > > I can't confirm with an AOOo Build, but I did check the OOO-dev 3.4 on >> win32 to see if the problem existed previously. I was able to password >> protect (encrypt) a simple Writer document. It saved and opened fine (after >> I gave the password again. >> > So this is maybe a regression > > What was interesting to me was that OO.o 2.4.1 (Novell Edition) failed to >> open the document and never got to recognizing that it was encrypted. I got >> a bad XML message, suggesting that an encrypted file was being mistakenly >> opened without decryption first. >> > I think, that has nothing to do with it. > > > Greetings Raphael > > > -- > My private Homepage: http://www.raphaelbircher.ch/ >
Re: AOOo can't save passwort protected file
On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton wrote: > I think reverting to Blowfish with 8-bit CFB and the default algorithms is a > good idea regardless. > I think that would be a very bad idea. We need to look beyond 2.4.1 compatibility and ask what the purpose of password protection is and how user uses it and why we switched to AES in the first place. If I was just sticking a file on the web for anyone to download it, then I'd have no knowledge or control over what application the user was using. In that case I'd personally use PDF. But if I needed the user to edit the doc then I'd post in ODF. But a password protected file? That is generally not a broadcast of a file to many unknown parties. It is typically a known-party document exchange. I can tell them that OOo 3.0 or above is required, I can respond if they have a problem. If I am password protecting a doc it is for data security purposes, not for interoperability purposes. So why did OOo have Blowfish in the first place. Flash back to 2000 when the OOo project started. Data Encryption Standard (DES) had been the most common method in use, especially in commerce. But it was known that the short key length (56 bits) would eventually be cracked. It was simply a matter of Moore's Law. One of the alternative algorithms at the time was Bruce Schneir's Blowfish, specified in a popular cryptography book at the time. It was especially attractive for OSS because the author made it available royalty free, So savvy OSS projects of the era, knowing that the DES key length was short. So that explains why OOo has it. And since OOo's format was the base of ODF 1.0, that explains why ODF has Blowfish. In parallel with this, the US government was running a competition for a replacement algorithm for DES. There were 15 submissions, including one by Bruce Schneir. But it wasn't Blowfish. It was a variation called Twofish. Twofish is used, for example, in OpenPGP. Bruce actually recommends today to not use Blowfish, but to use Twofish instead [1]. When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. There are regulations in several countries that specify what cryptographic methods may be used for government work. In the US this is called FIPS == Federal Information Processing Standards. There are similar rules, for example, in Japan. FIPS 140-2 recommends AES. It does not recommend Blowfish. So this has great relevance for government users, government contractors, as well as other sectors like healthcare. >From an international perspective, AES is also specified via ISO/IEC 18033-3:2010. So it is more acceptable for international trade. So from strength perspective, from government requirements, to international acceptability, AES is the preferred algorithm here. However, I do appreciate the backwards compatibility concerns. Maybe the way to solve this is to ensure that when a document is "Save As" to ODF 1.0/1.1 compatible, that we always use Blowfish. But when we save ODF 1.2, then we use AES, per the ODF 1.2 recommendation. But we might have also a box that a user could click if the wanted to save an ODF 1.2 doc using Blowfish. But I would not recommend this as the default. Another factor is that in some countries and for some uses, an algorithm selected by the US government is received with some suspicion and there may be alternative national mandates. So it probably makes sense to ensure that this area of the product is extensible, so if someone wanted to add additional algorithms, it could be easily done. [1] http://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/ But it was effectively cracked in 1999. They key length (56 bits) was just too short and Moore's Law had caught up with it. Since it was know One of the submitted algorithms was Blowfish. > I have confirmed that when OOo-dev 3.4 is set to save in ODF 1.0/1.1 format, > it will use the default algorithms for Password protection of files, as > expected. > > I also confirmed that saving in ODF 1.2 and ODF 1.2 extended format, the > aes256 algorithm is used. The resulting encrypted document will fail on open > with any of these releases: > > OpenOffice.org 2.4.1 > OpenOffice.org 3.2.0 > LibreOffice.org 3.3.2 > LibreOffice.org 3.4.3 > Lotus Symphony 3 fixpack3 > > Note that the only algorithm required to be supported by ODF 1.2 Package > consumers is the default Blowfish CFB. Other algorithms are admissible, but > none are recommended in the ODF 1.2 specification and only the one is > required. > > - Dennis > > -Original Message- > From: Mathias Bauer [mailto:mathias_ba...@gmx.net] > Sent: Friday, September 1
Re: AOOo can't save passwort protected file
Am 17.09.2011 14:44, schrieb Rob Weir: > When the competition for a new algorithm ended, the winner was the > Advanced Encryption Standard (AES). We really need to support that > algorithm. There is a reason why ODF 1.3 recommends it. There are > regulations in several countries that specify what cryptographic > methods may be used for government work. In the US this is called > FIPS == Federal Information Processing Standards. There are similar > rules, for example, in Japan. FIPS 140-2 recommends AES. It does not > recommend Blowfish. So this has great relevance for government users, > government contractors, as well as other sectors like healthcare. As you said, OOo *1.3* will *recommend* it. Does that require postponing an AOOo 3.4 release until there is a code replacement for nss? Or do you already have something to use? IIRC it took roughly two weeks to implement and test the new AES code for an engineer familiar with the code. I assume that for a newbie that would be quite some time more. IMHO getting 3.4 out fast is important. And of course having AES encryption is important also - immediately after that. YMMV. Regards, Mathias
RE: AOOo can't save passwort protected file
Rob, 1. There is no requirement in ODF 1.2 for consumers and producers to support anything but the default Blowfish with 8-bit CFB. 2. While producing and consuming aes256 is allowed in the specification, there is not even a "should" with respect to it. 3. Unilateral change to only producing aes256 when the save mode is 1.2 or 1.2 extended breaks all versions of earlier releases of OO.o, including earlier 3.x ones. It also breaks code on other releases based on the OO.o code base (LibreOffice through 3.4.3, Symphony through 3 fixpack3, etc.). 4. If aes256 were to be produced, it should be at user option with warning to the effect that the security used may limit the password being accepted on any software but that used to set the password. Since this is all still password-based security, and the biggest vulnerability is direct attack on the password, upgrading the encryption does not seem to be worth the disruption (unless the less-disruptive (4) is pursued). It would be good to put our heads together with LibreOffice and anyone else considering any introduction of new encryption methods in password-protected files. LO presumably has the copyleft code that is no longer usable by us. I see no enabling of it in LO producers so far. Collaboration on staging and maintenance of interoperability seems like a great opportunity in this area. The ODF Toolkit might provide some valuable reference cases as well. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, September 17, 2011 05:45 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton wrote: > I think reverting to Blowfish with 8-bit CFB and the default algorithms is a > good idea regardless. > I think that would be a very bad idea. We need to look beyond 2.4.1 compatibility and ask what the purpose of password protection is and how user uses it and why we switched to AES in the first place. If I was just sticking a file on the web for anyone to download it, then I'd have no knowledge or control over what application the user was using. In that case I'd personally use PDF. But if I needed the user to edit the doc then I'd post in ODF. But a password protected file? That is generally not a broadcast of a file to many unknown parties. It is typically a known-party document exchange. I can tell them that OOo 3.0 or above is required, I can respond if they have a problem. If I am password protecting a doc it is for data security purposes, not for interoperability purposes. So why did OOo have Blowfish in the first place. Flash back to 2000 when the OOo project started. Data Encryption Standard (DES) had been the most common method in use, especially in commerce. But it was known that the short key length (56 bits) would eventually be cracked. It was simply a matter of Moore's Law. One of the alternative algorithms at the time was Bruce Schneir's Blowfish, specified in a popular cryptography book at the time. It was especially attractive for OSS because the author made it available royalty free, So savvy OSS projects of the era, knowing that the DES key length was short. So that explains why OOo has it. And since OOo's format was the base of ODF 1.0, that explains why ODF has Blowfish. In parallel with this, the US government was running a competition for a replacement algorithm for DES. There were 15 submissions, including one by Bruce Schneir. But it wasn't Blowfish. It was a variation called Twofish. Twofish is used, for example, in OpenPGP. Bruce actually recommends today to not use Blowfish, but to use Twofish instead [1]. When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. There are regulations in several countries that specify what cryptographic methods may be used for government work. In the US this is called FIPS == Federal Information Processing Standards. There are similar rules, for example, in Japan. FIPS 140-2 recommends AES. It does not recommend Blowfish. So this has great relevance for government users, government contractors, as well as other sectors like healthcare. >From an international perspective, AES is also specified via ISO/IEC 18033-3:2010. So it is more acceptable for international trade. So from strength perspective, from government requirements, to international acceptability, AES is the preferred algorithm here. However, I do appreciate the backwards compatibility concerns. Maybe the way to solve this is to ensure that when a document is "Save As" to ODF 1.0/1.1 compatible, that we always use Blowfish. But when we save ODF 1.2, then we use AES, per the ODF 1.2 recommendation. But we might have also a box that a user could cli
Re: AOOo can't save passwort protected file
On 9/17/11, Dennis E. Hamilton wrote: > Rob, > > 1. There is no requirement in ODF 1.2 for consumers and producers to > support anything but the default Blowfish with 8-bit CFB. > Well, there is no requirement to support Blowfish either. Encryption is an optional feature. But for a large class of import users, AES is mandatory. Maybe not according to the standard, but by regulation. > 2. While producing and consuming aes256 is allowed in the specification, > there is not even a "should" with respect to it. > Again, I'm talking about user requirements, not the standard. > 3. Unilateral change to only producing aes256 when the save mode is 1.2 or > 1.2 extended breaks all versions of earlier releases of OO.o, including > earlier 3.x ones. It also breaks code on other releases based on the OO.o > code base (LibreOffice through 3.4.3, Symphony through 3 fixpack3, etc.). > There are many things in OOo 3.4 that an earlier version of OOo might not be able to process. The nice thing about OOo is earlier users are able to upgrade for free. And they always will be. In any case, I think this is a tradeoff that we might allow the intelligent user to make for themselves, interop with older versions of OOo versus greater security. > 4. If aes256 were to be produced, it should be at user option with warning > to the effect that the security used may limit the password being accepted > on any software but that used to set the password. > There are some apps, like MS Office, that won't process Blowfish-encrypted documents either. Maybe we should give a warning on all password protected documents? > Since this is all still password-based security, and the biggest > vulnerability is direct attack on the password, upgrading the encryption > does not seem to be worth the disruption (unless the less-disruptive (4) is > pursued). > Maybe to you, and according to your personal work habits this might be true. But try to think of other users here, maybe users who are trained to use proper passwords, customers in industries and sectors who are required to use FIPS 140-2 compliant algorithms. > It would be good to put our heads together with LibreOffice and anyone else > considering any introduction of new encryption methods in password-protected > files. LO presumably has the copyleft code that is no longer usable by us. > I see no enabling of it in LO producers so far. > Maybe put our heads together with users. Wider exposure to customer uses of encryption might broaden our thinking on the topic. > Collaboration on staging and maintenance of interoperability seems like a > great opportunity in this area. The ODF Toolkit might provide some valuable > reference cases as well. > > - Dennis > > -Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 05:45 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton > wrote: >> I think reverting to Blowfish with 8-bit CFB and the default algorithms is >> a good idea regardless. >> > > I think that would be a very bad idea. We need to look beyond 2.4.1 > compatibility and ask what the purpose of password protection is and > how user uses it and why we switched to AES in the first place. > > If I was just sticking a file on the web for anyone to download it, > then I'd have no knowledge or control over what application the user > was using. In that case I'd personally use PDF. But if I needed the > user to edit the doc then I'd post in ODF. But a password protected > file? That is generally not a broadcast of a file to many unknown > parties. It is typically a known-party document exchange. I can tell > them that OOo 3.0 or above is required, I can respond if they have a > problem. If I am password protecting a doc it is for data security > purposes, not for interoperability purposes. > > So why did OOo have Blowfish in the first place. Flash back to 2000 > when the OOo project started. Data Encryption Standard (DES) had been > the most common method in use, especially in commerce. But it was > known that the short key length (56 bits) would eventually be cracked. > It was simply a matter of Moore's Law. > > One of the alternative algorithms at the time was Bruce Schneir's > Blowfish, specified in a popular cryptography book at the time. It > was especially attractive for OSS because the author made it available > royalty free, So savvy OSS projects of the era, knowing that the DES > key length was short. > > So that explains why OOo has it. And since OOo's format was the base > of ODF 1.0, that explains why ODF has Blowfish. &
RE: AOOo can't save passwort protected file
Rob, What are you talking about? There is no new draft of Part 3 for ODF 1.3 and ODF 1.2 does *not* recommend AES. This has nothing to do with history lessons about NIST choice of encryption methods. (And did you know they are starting the look for AES replacement now?) In any case, I would be shocked to see ODF encryption use, with *any* encryption method whatsoever, in official secure communications or as a recommended method even for secure commercial communications. As you said earlier, ODF encryption is likely valuable mainly for confined, personal usage of "Save As ... Password Protected." There is no need to upgrade for that purpose, especially unilaterally without user control. Pity the user who has upgraded at home but not at the office (or vice versa) and who encrypted a file for carrying from one place to another and now can't open it at the destination. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, September 17, 2011 05:45 To: ooo-dev@incubator.apache.org Subject: Re: AOOo can't save passwort protected file On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton wrote: > I think reverting to Blowfish with 8-bit CFB and the default algorithms is a > good idea regardless. > [ ... ] When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. [ ... ]
Re: AOOo can't save passwort protected file
On 9/17/11, Mathias Bauer wrote: > Am 17.09.2011 14:44, schrieb Rob Weir: > >> When the competition for a new algorithm ended, the winner was the >> Advanced Encryption Standard (AES). We really need to support that >> algorithm. There is a reason why ODF 1.3 recommends it. There are >> regulations in several countries that specify what cryptographic >> methods may be used for government work. In the US this is called >> FIPS == Federal Information Processing Standards. There are similar >> rules, for example, in Japan. FIPS 140-2 recommends AES. It does not >> recommend Blowfish. So this has great relevance for government users, >> government contractors, as well as other sectors like healthcare. > > As you said, OOo *1.3* will *recommend* it. Does that require postponing > an AOOo 3.4 release until there is a code replacement for nss? Or do you > already have something to use? IIRC it took roughly two weeks to > implement and test the new AES code for an engineer familiar with the > code. I assume that for a newbie that would be quite some time more. > Support for AES exists in the JCE and via the ODF Toolkit. The later is Apache 2.0 licensed. > IMHO getting 3.4 out fast is important. And of course having AES > encryption is important also - immediately after that. > I'm flexible on the staging of this. Eventually we'll want to get to have full AES support. I've seen Microsoft push OOo out of consideration for government accounts by arguing that the MS Office crypto is certified and ours is using an algorithm (Blowfish) that is not, that OOo uses a cipher that even the author recommends not using. We don't win that debate with a backwards compatibility argument. > YMMV. > > Regards, > Mathias >
Re: AOOo can't save passwort protected file
On 9/17/11, Dennis E. Hamilton wrote: > Rob, > > What are you talking about? > > There is no new draft of Part 3 for ODF 1.3 and ODF 1.2 does *not* recommend > AES. > > This has nothing to do with history lessons about NIST choice of encryption > methods. (And did you know they are starting the look for AES replacement > now?) > > In any case, I would be shocked to see ODF encryption use, with *any* > encryption method whatsoever, in official secure communications or as a > recommended method even for secure commercial communications. > > As you said earlier, ODF encryption is likely valuable mainly for confined, > personal usage of "Save As ... Password Protected." There is no need to > upgrade for that purpose, especially unilaterally without user control. > Pity the user who has upgraded at home but not at the office (or vice versa) > and who encrypted a file for carrying from one place to another and now > can't open it at the destination. > That is one use. That is not the only use. I'm not arguing that we don't support Blowfish at all. I'm saying that we should also allow saving with AES, as allowed by ODF, and as required by regulation for many users. Your use of the word "unilaterally" is rhetorical nonsense. As I said before, I favor having option for the user to select the encryption method to use. We should try not to 2nd guess our users' preferences and offer only lowest-common-denominator, one-size-fits-all solutions. We should try to provide configuration options for reasonable alternatives, especially where we know different user populations will have different preferences. There are better ways to pity the poor user at home with a 3 year old version of OOo. For example, making it easier for them to know that their best option is to save the document on ODF 1.1 format. That solves this issue, and several others. > - Dennis > > -Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 05:45 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton > wrote: >> I think reverting to Blowfish with 8-bit CFB and the default algorithms is >> a good idea regardless. >> > > [ ... ] > > When the competition for a new algorithm ended, the winner was the > Advanced Encryption Standard (AES). We really need to support that > algorithm. There is a reason why ODF 1.3 recommends it. > > [ ... ] > >
RE: AOOo can't save passwort protected file
Concerning interoperability with Microsoft Office applications, 1. As far as I know encrypted ODF documents in any form are not accepted by Microsoft Office applications and there is no expectation that they are. 2. As far as I know, OpenOffice.org does not support any of the stronger encryption methods in Office 97-2000 and 2003 documents. Any superior encryption applied to OOXML documents is also not accepted. Nor does export from OpenOffice.org to Microsoft Office formats appear to support any Password Protection beyond the weaker of those supported at even the Office 97-2000 level. The OpenOffice.org user is not given any options to choose among. 3. It would be interesting to know which levels of encryption of Microsoft Office documents have been accepted for use in exchange or handling of official documents. It would also be interesting to know how such qualification was achieved. I have no idea. I don't follow the logic of communicating with people directly relying on the OO.o code base only if we also invite in the United Nations General Assembly. In any case, I am communicating with LibreOffice on matters of this kind as a private citizen (sort of Jimmy Carter in the small). I will not report back here. I think communication bridges are better served if LibreOffice experts and those of other related products speak for themselves here. I shall not continue any further on this line concerning presumptive user requirements. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, September 17, 2011 09:40 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: Re: AOOo can't save passwort protected file On 9/17/11, Dennis E. Hamilton wrote: > Rob, > > 1. There is no requirement in ODF 1.2 for consumers and producers to > support anything but the default Blowfish with 8-bit CFB. > Well, there is no requirement to support Blowfish either. Encryption is an optional feature. But for a large class of import users, AES is mandatory. Maybe not according to the standard, but by regulation. > 2. While producing and consuming aes256 is allowed in the specification, > there is not even a "should" with respect to it. > Again, I'm talking about user requirements, not the standard. > 3. Unilateral change to only producing aes256 when the save mode is 1.2 or > 1.2 extended breaks all versions of earlier releases of OO.o, including > earlier 3.x ones. It also breaks code on other releases based on the OO.o > code base (LibreOffice through 3.4.3, Symphony through 3 fixpack3, etc.). > There are many things in OOo 3.4 that an earlier version of OOo might not be able to process. The nice thing about OOo is earlier users are able to upgrade for free. And they always will be. In any case, I think this is a tradeoff that we might allow the intelligent user to make for themselves, interop with older versions of OOo versus greater security. > 4. If aes256 were to be produced, it should be at user option with warning > to the effect that the security used may limit the password being accepted > on any software but that used to set the password. > There are some apps, like MS Office, that won't process Blowfish-encrypted documents either. Maybe we should give a warning on all password protected documents? > Since this is all still password-based security, and the biggest > vulnerability is direct attack on the password, upgrading the encryption > does not seem to be worth the disruption (unless the less-disruptive (4) is > pursued). > Maybe to you, and according to your personal work habits this might be true. But try to think of other users here, maybe users who are trained to use proper passwords, customers in industries and sectors who are required to use FIPS 140-2 compliant algorithms. > It would be good to put our heads together with LibreOffice and anyone else > considering any introduction of new encryption methods in password-protected > files. LO presumably has the copyleft code that is no longer usable by us. > I see no enabling of it in LO producers so far. > Maybe put our heads together with users. Wider exposure to customer uses of encryption might broaden our thinking on the topic. > Collaboration on staging and maintenance of interoperability seems like a > great opportunity in this area. The ODF Toolkit might provide some valuable > reference cases as well. > > - Dennis > > -Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 05:45 > To: ooo-dev@incubator.apache.org > Subject: Re: AOOo can't save passwort protected file > > On Fri, Sep 16, 2011 at 7:51 PM, Dennis E. Hamilton > wrote: >> I think reverting to Blowfish with 8-bit CFB and the default algorithms is >> a good
RE: AOOo can't save passwort protected file
I am not disagreeing with provision of an user option. That is not what the current OOo-dev 3.4 does. That's not what the current build attempts to do. That's pretty damned unilateral, Rob. That is what I was referring to. In a reply to Mathias, you mentioned certification of document cryptography. Does that require something more than declaring there is a way to use aes in an ODF Package encryption? Perhaps it is important to know what the certification requirements are? - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, September 17, 2011 09:58 To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org Subject: Re: AOOo can't save passwort protected file [ ... ] I'm not arguing that we don't support Blowfish at all. I'm saying that we should also allow saving with AES, as allowed by ODF, and as required by regulation for many users. Your use of the word "unilaterally" is rhetorical nonsense. As I said before, I favor having option for the user to select the encryption method to use. We should try not to 2nd guess our users' preferences and offer only lowest-common-denominator, one-size-fits-all solutions. We should try to provide configuration options for reasonable alternatives, especially where we know different user populations will have different preferences. [ ... ]
Re: AOOo can't save passwort protected file
On Sat, Sep 17, 2011 at 1:07 PM, Dennis E. Hamilton wrote: > Concerning interoperability with Microsoft Office applications, > > 1. As far as I know encrypted ODF documents in any form are not accepted by > Microsoft Office applications and there is no expectation that they are. > > 2. As far as I know, OpenOffice.org does not support any of the stronger > encryption methods in Office 97-2000 and 2003 documents. Any superior > encryption applied to OOXML documents is also not accepted. Nor does export > from OpenOffice.org to Microsoft Office formats appear to support any > Password Protection beyond the weaker of those supported at even the Office > 97-2000 level. The OpenOffice.org user is not given any options to choose > among. > > 3. It would be interesting to know which levels of encryption of Microsoft > Office documents have been accepted for use in exchange or handling of > official documents. It would also be interesting to know how such > qualification was achieved. I have no idea. > It occurs through FIPS 140 certification.Here's an example of how this is invoked from a regulation: http://www.gpo.gov/fdsys/pkg/CFR-2010-title48-vol4/pdf/CFR-2010-title48-vol4-sec352-239-71.pdf "352.239–71 Standard language.for encryption" As prescribed in 339.101(d)(2), the Contracting Officer shall insert the following clause: STANDARD FOR ENCRYPTION LANGUAGE (JANUARY 2010) (a) The Contractor shall use Federal Infor- mation Processing Standard (FIPS) 140–2- compliant encryption (Security Require- ments for Cryptographic Module, as amend- ed) to protect all instances of HHS sensitive information during storage and trans- mission." So to do business with the agency (in this case Department of Heath and Human Services) you need to be using validated encryption modules. This requires the use of approved algorithms. > I don't follow the logic of communicating with people directly relying on the > OO.o code base only if we also invite in the United Nations General Assembly. > In any case, I am communicating with LibreOffice on matters of this kind as a > private citizen (sort of Jimmy Carter in the small). I will not report back > here. I think communication bridges are better served if LibreOffice experts > and those of other related products speak for themselves here. > > I shall not continue any further on this line concerning presumptive user > requirements. > This is not presumptive. US Federal regulations are published online Anyone can look them up, Similar regulations exist in Europe and in Japan. > - Dennis > > -Original Message- > From: Rob Weir [mailto:robw...@apache.org] > Sent: Saturday, September 17, 2011 09:40 > To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org > Subject: Re: AOOo can't save passwort protected file > > On 9/17/11, Dennis E. Hamilton wrote: >> Rob, >> >> 1. There is no requirement in ODF 1.2 for consumers and producers to >> support anything but the default Blowfish with 8-bit CFB. >> > > Well, there is no requirement to support Blowfish either. Encryption > is an optional feature. But for a large class of import users, AES is > mandatory. Maybe not according to the standard, but by regulation. > >> 2. While producing and consuming aes256 is allowed in the specification, >> there is not even a "should" with respect to it. >> > > Again, I'm talking about user requirements, not the standard. > >> 3. Unilateral change to only producing aes256 when the save mode is 1.2 or >> 1.2 extended breaks all versions of earlier releases of OO.o, including >> earlier 3.x ones. It also breaks code on other releases based on the OO.o >> code base (LibreOffice through 3.4.3, Symphony through 3 fixpack3, etc.). >> > > There are many things in OOo 3.4 that an earlier version of OOo might > not be able to process. The nice thing about OOo is earlier users are > able to upgrade for free. And they always will be. > > In any case, I think this is a tradeoff that we might allow the > intelligent user to make for themselves, interop with older versions > of OOo versus greater security. > >> 4. If aes256 were to be produced, it should be at user option with warning >> to the effect that the security used may limit the password being accepted >> on any software but that used to set the password. >> > > There are some apps, like MS Office, that won't process > Blowfish-encrypted documents either. Maybe we should give a warning > on all password protected documents? > >> Since this is all still password-based security, and the biggest >> vulnerability is direct attack on the password, upgrading the encryption &
Re: AOOo can't save passwort protected file
Hi; Despite the valid interest in higher encryption schemes, I prefer to set Blowfish as default now. That doesn't mean we won't consider patches later on, of course. BTW, can't we just use OpenSSL? I think it's included in most linux/BSD distributions. Pedro. On Sat, 17 Sep 2011 12:47:59 -0400, Rob Weir wrote: On 9/17/11, Mathias Bauer wrote: Am 17.09.2011 14:44, schrieb Rob Weir: When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. There are regulations in several countries that specify what cryptographic methods may be used for government work. In the US this is called FIPS == Federal Information Processing Standards. There are similar rules, for example, in Japan. FIPS 140-2 recommends AES. It does not recommend Blowfish. So this has great relevance for government users, government contractors, as well as other sectors like healthcare. As you said, OOo *1.3* will *recommend* it. Does that require postponing an AOOo 3.4 release until there is a code replacement for nss? Or do you already have something to use? IIRC it took roughly two weeks to implement and test the new AES code for an engineer familiar with the code. I assume that for a newbie that would be quite some time more. Support for AES exists in the JCE and via the ODF Toolkit. The later is Apache 2.0 licensed. IMHO getting 3.4 out fast is important. And of course having AES encryption is important also - immediately after that. I'm flexible on the staging of this. Eventually we'll want to get to have full AES support. I've seen Microsoft push OOo out of consideration for government accounts by arguing that the MS Office crypto is certified and ours is using an algorithm (Blowfish) that is not, that OOo uses a cipher that even the author recommends not using. We don't win that debate with a backwards compatibility argument. YMMV. Regards, Mathias
Re: AOOo can't save passwort protected file
Am 17.09.2011 18:47, schrieb Rob Weir: > On 9/17/11, Mathias Bauer wrote: >> Am 17.09.2011 14:44, schrieb Rob Weir: >> >>> When the competition for a new algorithm ended, the winner was the >>> Advanced Encryption Standard (AES). We really need to support that >>> algorithm. There is a reason why ODF 1.3 recommends it. There are >>> regulations in several countries that specify what cryptographic >>> methods may be used for government work. In the US this is called >>> FIPS == Federal Information Processing Standards. There are similar >>> rules, for example, in Japan. FIPS 140-2 recommends AES. It does not >>> recommend Blowfish. So this has great relevance for government users, >>> government contractors, as well as other sectors like healthcare. >> >> As you said, OOo *1.3* will *recommend* it. Does that require postponing >> an AOOo 3.4 release until there is a code replacement for nss? Or do you >> already have something to use? IIRC it took roughly two weeks to >> implement and test the new AES code for an engineer familiar with the >> code. I assume that for a newbie that would be quite some time more. >> > > Support for AES exists in the JCE and via the ODF Toolkit. The later > is Apache 2.0 licensed. > >> IMHO getting 3.4 out fast is important. And of course having AES >> encryption is important also - immediately after that. >> > > I'm flexible on the staging of this. Eventually we'll want to get to > have full AES support. I've seen Microsoft push OOo out of > consideration for government accounts by arguing that the MS Office > crypto is certified and ours is using an algorithm (Blowfish) that is > not, that OOo uses a cipher that even the author recommends not using. > We don't win that debate with a backwards compatibility argument. Sure, I wasn't aiming at backwards compatibility. In fact I was one of those who where responsible for adding AES encryption to OOo's ODF code, for the same reasons as yours. I just recommended giving the urgency of a 3.4 release a higher priority than the usage of AES encryption for saving ODF 1.2 documents in that release. Regards, Mathias
Re: AOOo can't save passwort protected file
On Sat, Sep 17, 2011 at 1:26 PM, Pedro Giffuni wrote: > Hi; > > Despite the valid interest in higher encryption schemes, I > prefer to set Blowfish as default now. That doesn't mean > we won't consider patches later on, of course. > > BTW, can't we just use OpenSSL? I think it's included in > most linux/BSD distributions. > OpenSSL is a a validated module when run in "FIPS mode": http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm# But that would still apply to AES, not Blowfish. Think of it this way: FIPS 140 defines what the acceptable algorithms are. Then the actual modules, the actual libraries, are validated by 3rd party testing labs according to NIST criteria. If we use validated modules implementing approved algorithms, then we're golden. I'd be happy if we had deep in some configuration dialog the ability for user (or more likely the IT department) to specify the algorithm to use. The question of the default setting is less critical. The organizations that are most concerned about crypto tend to also be the organizations that will customize their installs to override the default settings for all users in their organizations. So if we want the Apache-released version to use Blowfish by default, that is fine. This is something that we should keep in mind in general. Microsoft does a great job with their Office Resource Kit and the ability for corporate users to customize and deploy installs in their organizations with different defaults. We should aim for similar capabilities for AOOo,. So think of two kinds of users; 1) Those who download a single copy of AOOo and install it on a single machine, or a small number of machines. 2) Those who customize the install, add additional corporate templates, override settings, etc., and deploy to thousands of users. We might have great ideas for what settings we have as defaults for that first class of users. But we should also enable IT departments to enforce their own requirements for their own users. The defaults appropriate for installing on 40 machines for use by patrons in a public library might be different than the defaults for 100,000 users at a Fortune 500 company. Does that make sense? -Rob > Pedro. > > On Sat, 17 Sep 2011 12:47:59 -0400, Rob Weir wrote: >> >> On 9/17/11, Mathias Bauer wrote: >>> >>> Am 17.09.2011 14:44, schrieb Rob Weir: >>> When the competition for a new algorithm ended, the winner was the Advanced Encryption Standard (AES). We really need to support that algorithm. There is a reason why ODF 1.3 recommends it. There are regulations in several countries that specify what cryptographic methods may be used for government work. In the US this is called FIPS == Federal Information Processing Standards. There are similar rules, for example, in Japan. FIPS 140-2 recommends AES. It does not recommend Blowfish. So this has great relevance for government users, government contractors, as well as other sectors like healthcare. >>> >>> As you said, OOo *1.3* will *recommend* it. Does that require postponing >>> an AOOo 3.4 release until there is a code replacement for nss? Or do you >>> already have something to use? IIRC it took roughly two weeks to >>> implement and test the new AES code for an engineer familiar with the >>> code. I assume that for a newbie that would be quite some time more. >>> >> >> Support for AES exists in the JCE and via the ODF Toolkit. The later >> is Apache 2.0 licensed. >> >>> IMHO getting 3.4 out fast is important. And of course having AES >>> encryption is important also - immediately after that. >>> >> >> I'm flexible on the staging of this. Eventually we'll want to get to >> have full AES support. I've seen Microsoft push OOo out of >> consideration for government accounts by arguing that the MS Office >> crypto is certified and ours is using an algorithm (Blowfish) that is >> not, that OOo uses a cipher that even the author recommends not using. >> We don't win that debate with a backwards compatibility argument. >> >>> YMMV. >>> >>> Regards, >>> Mathias >>> > >
Re: AOOo can't save passwort protected file
Am 17.09.2011 19:26, schrieb Pedro Giffuni: > Hi; > > Despite the valid interest in higher encryption schemes, I > prefer to set Blowfish as default now. That doesn't mean > we won't consider patches later on, of course. Ah, you used the magic word. :-) So for those who want to have AES encryption in 3.4: send patches! Regards, Mathias
Re: AOOo can't save passwort protected file
--- On Sat, 9/17/11, Rob Weir wrote: ... > > OpenSSL is a a validated module when run in "FIPS mode": > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm# > > But that would still apply to AES, not Blowfish. > > Think of it this way: FIPS 140 defines what the > acceptable algorithms are. Then the actual modules, > the actual libraries, are validated by 3rd party > testing labs according to NIST criteria. If we use > validated modules implementing approved algorithms, then > we're golden. > Thanks for this point. NSS is not certified and given the version OOo carries has known security issues I suggest we kill the configure option to avoid hazards to our users. Without other options I prefer Blowfish to no security at all. Again, patches for OpenSSL or any other certified solution are welcome :). While here .. I also think we should kill mozilla: 1) The version we carry also has serious security issues. 2) Google Chromium has a better license. 3) I actually think we should be browser version agnostic. > I'd be happy if we had deep in some configuration dialog > the ability for user (or more likely the IT department) > to specify the algorithm to use. > I would think it could be a compile time option so we could name such switch "configure --with-ssl". See? Everyone happy now :). Cheers, Pedro.
Re: AOOo can't save passwort protected file
Hi again; I think I found the missing piece in the puzzle ... OOo already uses OpenSSL, but in order to replace nss we need support for xmlsecurity. This library provides just that under an MIT license: http://www.aleksey.com/xmlsec/ Alternatively Apache has it's own stuff: http://santuario.apache.org/ Cheers, Pedro.
Re: AOOo can't save passwort protected file
Ugh ... nevermind, we already carry xmlsec ! I guess we have everything to get rid of nss but we are not using it right? Apache Santuario is interesting though. Cheers, Pedro.
Re: AOOo can't save passwort protected file
Am 18.09.2011 06:10, schrieb Pedro F. Giffuni: > Ugh ... nevermind, we already carry xmlsec ! > > I guess we have everything to get rid of nss but we are not using it right? > Apache Santuario is interesting though. > > Cheers, Pedro. The reason why we went for nss when we needed AES enryption was code quality. openssl was considered as badly maintained. Disclaimer: I just repeat what the engineer charged with the evaluation reported. I didn't carry out this evaluation by myself. Regards, Mathias
Re: AOOo can't save passwort protected file
Hi Matias; On Mon, 19 Sep 2011 22:06:56 +0200, Mathias Bauer wrote: Am 18.09.2011 06:10, schrieb Pedro F. Giffuni: Ugh ... nevermind, we already carry xmlsec ! I guess we have everything to get rid of nss but we are not using it right? Apache Santuario is interesting though. Cheers, Pedro. The reason why we went for nss when we needed AES enryption was code quality. openssl was considered as badly maintained. Disclaimer: I just repeat what the engineer charged with the evaluation reported. I didn't carry out this evaluation by myself. Thanks for the explanation. That might have been a valid reason then. The latest version is dated from less than 2 weeks ago, so it looks pretty well maintained now :). Just a thought ... Perhaps we should try to make Apache OO *really* Apache. I am now seeing so many nice things that other Apache projects offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something to consider (after 3.4). Cheers, Pedro.
Re: AOOo can't save passwort protected file
Am 19.09.2011 23:07, schrieb Pedro Giffuni: > Hi Matias; > > On Mon, 19 Sep 2011 22:06:56 +0200, Mathias Bauer > wrote: >> Am 18.09.2011 06:10, schrieb Pedro F. Giffuni: >> >>> Ugh ... nevermind, we already carry xmlsec ! >>> >>> I guess we have everything to get rid of nss but we are not using it >>> right? Apache Santuario is interesting though. >>> >>> Cheers, Pedro. >> >> The reason why we went for nss when we needed AES enryption was code >> quality. openssl was considered as badly maintained. >> >> Disclaimer: I just repeat what the engineer charged with the >> evaluation >> reported. I didn't carry out this evaluation by myself. >> > Thanks for the explanation. > > That might have been a valid reason then. The latest version is dated > from less than 2 weeks ago, so it looks pretty well maintained now :). > > Just a thought ... Perhaps we should try to make Apache OO *really* > Apache. I am now seeing so many nice things that other Apache projects > offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something > to consider (after 3.4). Whatever external components are added: it should be avoided to use Java components for code that is loaded on startup or for loading "normal" documents. If possible, Java should be used only for optional components/features. Regards, Mathias
Re: AOOo can't save passwort protected file
On Mon, 19 Sep 2011 23:34:22 +0200, Mathias Bauer wrote: ... Just a thought ... Perhaps we should try to make Apache OO *really* Apache. I am now seeing so many nice things that other Apache projects offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something to consider (after 3.4). Whatever external components are added: it should be avoided to use Java components for code that is loaded on startup or for loading "normal" documents. If possible, Java should be used only for optional components/features. Except for pdfbox, all the Apache conponents I mentioned are available in C/C++ versions. Cheers, Pedro.
Re: AOOo can't save passwort protected file
On Mon, 19 Sep 2011 16:42:22 -0500, Pedro Giffuni wrote: On Mon, 19 Sep 2011 23:34:22 +0200, Mathias Bauer wrote: ... Just a thought ... Perhaps we should try to make Apache OO *really* Apache. I am now seeing so many nice things that other Apache projects offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something to consider (after 3.4). Whatever external components are added: it should be avoided to use Java components for code that is loaded on startup or for loading "normal" documents. If possible, Java should be used only for optional components/features. Except for pdfbox, all the Apache conponents I mentioned are available in C/C++ versions. (I was on my way out so I left this sort of half answered) The issue here is xmlsec as we have it now depends on nss and openssl. Apache Santuario has xml-security-c which only depends on openssl (and Xerces-c3). The Apache way would be to use Santuario, but that is probably more work than finding out why we are not using xmlsec + openssl. In both cases we should also update OpenSSL for security reasons. Pedro.
Re: AOOo can't save passwort protected file
On 17.09.2011 22:32, Pedro F. Giffuni wrote: > > > --- On Sat, 9/17/11, Rob Weir wrote: > ... >> >> OpenSSL is a a validated module when run in "FIPS mode": >> >> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm# >> >> But that would still apply to AES, not Blowfish. >> >> Think of it this way: FIPS 140 defines what the >> acceptable algorithms are. Then the actual modules, >> the actual libraries, are validated by 3rd party >> testing labs according to NIST criteria. If we use >> validated modules implementing approved algorithms, then >> we're golden. >> > > Thanks for this point. NSS is not certified and given the where the heck did you get that idea? http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280 > version OOo carries has known security issues I suggest > we kill the configure option to avoid hazards to our users. indeed the version shipped by OOo is outdated (3.12.6); newest one on the FTP server is: https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/ (of course the OOo internal OpenSSL is similarly out of date...) > Without other options I prefer Blowfish to no security at all. > Again, patches for OpenSSL or any other certified solution > are welcome :). > > While here .. I also think we should kill mozilla: > > 1) The version we carry also has serious security issues. > 2) Google Chromium has a better license. but can Google Chromium read Mozilla address books? AFAIK that is all that OOo uses Mozilla for... > 3) I actually think we should be browser version agnostic. > >> I'd be happy if we had deep in some configuration dialog >> the ability for user (or more likely the IT department) >> to specify the algorithm to use. >> > > I would think it could be a compile time option so we could > name such switch "configure --with-ssl". > > See? Everyone happy now :). > > Cheers, > > Pedro.
Re: AOOo can't save passwort protected file
Hi; --- On Thu, 9/22/11, Michael Stahl wrote: ... > > Thanks for this point. NSS is not certified and given > the > > where the heck did you get that idea? > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280 > Ugh.. there's something broken in the iPad safari search option. OK, it's still not too easy to ship NSS with Apache OO and we already have OpenSSL anyways. ... > > While here .. I also think we should kill mozilla: > > > > 1) The version we carry also has serious security > issues. > > 2) Google Chromium has a better license. > > but can Google Chromium read Mozilla address books? > > AFAIK that is all that OOo uses Mozilla for... > I thought it was to use embedded links in documents. Mozilla address books can continue being optional, I'd just be more tempted to use just mozilla thunderbird for that. cheers, Pedro.
Re: AOOo can't save passwort protected file
Am 22.09.2011 17:49, schrieb Michael Stahl: > On 17.09.2011 22:32, Pedro F. Giffuni wrote: >> >> >> --- On Sat, 9/17/11, Rob Weir wrote: >> ... >>> >>> OpenSSL is a a validated module when run in "FIPS mode": >>> >>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2009.htm# >>> >>> But that would still apply to AES, not Blowfish. >>> >>> Think of it this way: FIPS 140 defines what the >>> acceptable algorithms are. Then the actual modules, >>> the actual libraries, are validated by 3rd party >>> testing labs according to NIST criteria. If we use >>> validated modules implementing approved algorithms, then >>> we're golden. >>> >> >> Thanks for this point. NSS is not certified and given the > > where the heck did you get that idea? > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1280 > >> version OOo carries has known security issues I suggest >> we kill the configure option to avoid hazards to our users. > > indeed the version shipped by OOo is outdated (3.12.6); newest one on the > FTP server is: > > https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/ > > (of course the OOo internal OpenSSL is similarly out of date...) > >> Without other options I prefer Blowfish to no security at all. >> Again, patches for OpenSSL or any other certified solution >> are welcome :). >> >> While here .. I also think we should kill mozilla: >> >> 1) The version we carry also has serious security issues. >> 2) Google Chromium has a better license. > > but can Google Chromium read Mozilla address books? > > AFAIK that is all that OOo uses Mozilla for... AFAIR a genius has bound our whole address book support code (not only the code for the Mozilla address book) to Mozilla code. And we also use the Mozilla stuff for ldap. All other formerly Mozilla based functionality in OOo nowadays uses nss. All just IIRC. Regards, Mathias
Re: AOOo can't save passwort protected file
Hi Mathias, > AFAIR a genius has bound our whole address book support code (not only > the code for the Mozilla address book) to Mozilla code. And we also use > the Mozilla stuff for ldap. All other formerly Mozilla based > functionality in OOo nowadays uses nss. That's correct. Well, except the "genius" thingie :) Outlook, Outlook Express, LDAP, SeaMonkey, Thunderbird address books - all of those are accessed in OOo via the binary SeaMonkey code it ships. The NSS code in SeaMonkey is not used, but the (somewhat less outdated) in module nss. Ciao Frank
