Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

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...