Apache OpenOffice (AOO) Bugzilla – Issue 121499
If Microsoft Word adds another signature to document originally signed by OOo it causes OOo to prompt saying file is corrupt
Last modified: 2012-12-19 03:27:46 UTC
Created attachment 80037 [details] A file that exhibits this behaviour. This one was signed by LibreOffice, but the bug is the same. When MS Word adds a signature to a document which was originally signed by Ooo, Ooo then reports the document as being corrupt. Repro steps: 1) Boot Ooo 3) Under File menu, click Digital Signatures 4) Now click "Sign Document" button, agree to save the document and add a digital signature using a SHA1 cert 5) Exit Ooo 6) Open file you just created in MS Word (signature is considered valid) 8) File -> Info -> Protect Document -> Add a Digital signature 9) Choose an RSA certificate that uses a SHA1 hash (DSA is fine too) 10) Click Sign 11) Notice signatures are considered valid by Word (are on reopen too) 12) Exit Word 13) Open document in Ooo Expected: For file to open file and signatures to be considered valid Actual: Ooo will prompt saying the file is corrupt and needs to be repaired We think the signatures are being stored correctly by MS Word, and that this is a Ooo bug on open. I have also filed an identical bug for LibreOffice (https://bugs.freedesktop.org/show_bug.cgi?id=58442)
Created attachment 80038 [details] Examples of the Error Dialogs [zip] This is apparently in common code. There are *two* errors reported by OpenOffice family applications. The first error is that the file is corrupted. On requesting that repair be attempted, the second dialog reports that the signature is unverifiable. On accepting the document anyhow, it opens just fine, with its one word, "hello". The attached Zip demonstrates the pairs of messages from LibreOffice 3.3.2, Apache OpenOffice 3.4.1, and LibreOffice 3.6.4. Before inspecting the META-INF/manifest.xml and META-INF/documentsignatures.xml I'm going to first prepare a dual-signature version where AOO 3.4.1 is used to countersign the LibO 3.6.4 one. The we can see how that compares with the countersigning by Microsoft Office Word.
Created attachment 80044 [details] Bringing Dual Signature to Word 2013 Preview [Zip] This package produces a dual-signed ODT document starting in OpenOffice-lineage software and brings it to Microsoft Office Word 2013 Preview to confirm that incoming dual signatures are recognized properly in Word 2013. This also provides a basis for comparison with Chris Rae's upload of the document that, when counter-signed in Word 2013, is not acceptable to OpenOffice-lineage software. Here's the drill: 1. The "MSW2013pre-recover.png" shows the messages that Microsoft Office Word 2013 Preview presents when opening attachment 80037 [details], "A file that exhibits this behavior." The file is opened read-only initially, in a reading pane because the file is marked as final and is an Internet download. On selecting the option to make it editable, the presence of a signature is reported and it requires confirmation to make editable anyhow. The interesting feature of this case is the message that there are *recoverable* signatures in the file. This is for comparison with the reverse-path case. 2. The ODT, "orcmid-#2" was created and signed in LibreOffice 3.6.4, the latest release of that software. It was then countersigned using Apache OpenOffice 3.4.1. That is the file included in the package. 3. The snapshot, "orcmid-#2-sigs", shows the confirmation of the dual signatures back in LibreOffice 3.6.4. 4. The snapshot, "#2-MSW-ok" is how the signature is confirmed when the ODT (2) is opened in Microsoft Office Word 2013 Preview. Note that there is nothing about "recoverable" signatures. The document is recognized as signed. In working up this case, I ran into another one that may provide more clues. I'll provide that next.
Again, the symptoms are confirmed. It remains to understand what variations in the files are troublesome.
(In reply to comment #2) > In working up this case, I ran into another one that may provide more clues. > I'll provide that next. What I noticed is what Chris Rae reported in #121505.