The introduction of new encryption methods in the LO 3.5.x lineage by default leads to documents that cannot be opened by downlevel (e.g., LO 3.4.3, LO 3.3.2, OOo 3.3.0, LotusSymphony 3.0.1) consumers. This same problem occurs with OOo-dev 3.4.0 (Oracle built) and current AOO 3.4 developer previews. A more-extensive description of tests and a proposed remedy is found on Apache OpenOffice bugzilla: https://issues.apache.org/ooo/show_bug.cgi?id=119090
Created attachment 58718 [details] Change so that interoperable encryption is used by default * Alter the default UseSHA1InODF12 and UseBlowFishInODF12 settings to True so that the automatic behavior is to create encryptions that can be decrypted by any ODF 1.0/1.1/1.2 Consumer. AES256 encrypted packages can still be accepted correctly. Users who want to use AES256 and can limit the recipients to AES256-accepting implementations can change the settings to false in the user configuration information.
Created attachment 58719 [details] PATCH: Correct settings so taht default encryption is interoperable across ODF 1.0/1.1/1.2 implementations * Alter the default UseSHA1InODF12 and UseBlowFishInODF12 settings to True so that the automatic behavior is to create encryptions that can be decrypted by any ODF 1.0/1.1/1.2 Consumer. AES256 encrypted packages can still be accepted correctly. Users who want to use AES256 and can limit the recipients to AES256-accepting implementations can change the settings to false in the user configuration information.. [Sorry, I forgot to check the patch box on the first upload, and then Bugzilla treats it as a binary file. -- orcmid]
bug 40006 is connected
(In reply to comment #3) > bug 40006 is connected I assume that bug is closed because consumption of the AES256 encryptions was backported? So do you still intend to produce AES256 by default in future LO 3.5.x versions? That does nothing for interoperability, it just means those documents can't be consumed by anything but AES256 acceptors. And that is a small world at the moment. For anyone else, they get to deal with the strange error messages about defects in parts of the ODF document. If you change the default, and give folks the choice to opt-in to AES256, rather than having to learn to opt-out, it is a lot kinder to non-expert users, seems to me.
Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8475d4e14ce068b5eae155aa26f40f79ebadc0e2&g=libreoffice-3-5 Fix fdo#47484 - use older ODF encryption by default It will be available in LibreOffice 3.5.3.
Let's fix that for 3.5.x, and swap the default for 3.6 - that should give actively maintained other projects time to adapt.
Fixed in the libreoffice-3-5 branch
Note to users of 3.5.3 and beyond - if you've touched settings in Tools->Options->Save->General, LibreOffice potentially stored the previous defaults in your user configuration directory. Clearing the user configuration solves that issue (see http://ask.libreoffice.org/question/484/template-aggro for a description).
Related: bug 50703