On 11/11/11 10:50, Stephan Bergmann wrote: > With LO 3.5 by default using (new in ODF 1.2) AES encryption for > password-protected documents (instead of Blowfish as used in older > versions), people still using LO 3.4 would be unable to open such > documents. (And what's really ugly, all they would get is an > incomprehensible error box "Format error discovered in the file in > sub-document styles.xml at 1,0 (row,col).") > > <http://pkgs.fedoraproject.org/gitweb/?p=libreoffice.git;a=blob;f=Backport-reading-AES-encrypted-ODF-1.2-documents.patch;h=e6c722598ab05464f09787355b621cbb0aa07c49;hb=e7a803540d408adab3d55fb2ae051ac4be599a72> > > is a patch (actually, four separate patches for the components, > lib-core, lib-gui, and ure repos) to backport support for reading (but > not writing) AES-encrypted ODF 1.2 documents to libreoffice-3-4. It is > effectively all of CWS mav60 plus one additional typo fix, minus the > writing support from mav60, and as such is quite large.
usually i would be concerned about integrating a patch of this size into 3.4, but i think there are significant interop benefits in this case, so i am all for it. also, the CWS mav60 is already integrated in AOOo, so it will be part of their 3.4 release (whenever that is...). > An alternative might be to cherry-pick the relevant commits from master > into libreoffice-3-4, but that would have the drawback that it would > cause later LO 3.4.y to write password-protected ODF documents using AES > which earlier LO 3.4.x could no longer open---something that might not > be desirable for a micro update. Plus, the number of commits that would > need to be picked would be quite large, too (the individual commits of > mav60 are quite intertwined). > > If people are happy with the linked patch: fine. If people would prefer > a cherry-picking approach, I could post a list of relevant commits > (technically, I produced the patch in a different way, more or less > applying mav60 to libreoffice-3-4 directly, so do not have that list > handy). (And if there are objections against including this in the 3.4 > code line at all, that would of course be fine as well.) actually i'd prefer something that is ~close to the whole thing, because we don't have the original author around, and i guess there is probably a risk of missing some inter-dependencies when cherry-picking. regards, michael PS: just let me add a lament that the ManifestImport class also follows the ridiculous pattern of having dozens of constant string instance members... _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice