Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index

On 4 juin 12, at 23:39, Dennis E. Hamilton wrote:
Corruption could indeed be triggered by there being an inconsistency between META-INF/manifest.xml and what is present in the package.

It is interesting if that is a complaint about Configurations/.../ current.xml (usually a zero-length useless component), which is private information from the producer that is not defined by ODF and can't be meaningfully used by any software other than the producer. For the most part, that material appears to be gratuitous and unnecessary.

The missing Thumbnails/thumbnail.png is also benign.

Working from memory in order to reply quickly, I believe that there *IS* an ODF requirement for every stream in the package (a Zip) to be accounted for in META-INF/manifest.xml except the manifest itself, mimetype, and anything else in META-INF/ (except if it is meant to be encryptable). I suspect the specifications are silent concerning META-INF/manifest.xml entries that have no corresponding stream in the Zip. I need to confirm the facts.

Thanks for the hints. Worked on that, but no luck so far: I removed the references to the non-existing files and directories in the META- INF/manifest.xml file, but the document is still reported as corrupt. Then I did the reverse: keeping the existing META-INF/manifest.xml file and copying all the missing files and directories from the repaired document: LO still says the document is corrupt… I've checked the manifest.xml file thoroughly, and it does reference exactly all the files in the document, except everything in the META-INF directory itself and the mimetype file.

I would not be surprised if this tightening of consistency with the manifest is for purposes of improved detection of tampering and the possible incidence of a security exploit of one kind or another. There is a practice in security cases to avoid providing details since it provides too much information for someone attempting to craft an exploit. That's a stretch in this case.

This was what came to my mind too…

It would be useful to soften the message to one of "There are inconsistencies and it is possible the document is corrupted." The request for permission to attempt correction by eliminating the inconsistencies should be quite clear. It would also be valuable to report whether there was any apparent data loss or that repair did not involve loss of anything critical to the document. Encouraging a save-as of the repaired document to a different location would also be handy in restoring the confidence of the user in the successful effort.

Well again, telling the reason why the document is reported as corrupt would be a great help too. As it is now, we have to rely on wild guesses to figure out what to correct in the generated document, and that's a long and painful thing to do…

Anyway, thanks a lot again for your answers.
 - Eric -

For unsubscribe instructions e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.