Created attachment 71705 [details] A file that exhibits this behaviour - signed by LO, then Word. When MS Word adds a signature to a document which was originally signed by LibreOffice, LibreOffice then reports the document as being corrupt. Repro steps: 1) Boot LibreOffice 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 LibreOffice 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 LibreOffice Expected: For file to open file and signatures to be considered valid Actual: LibreOffice 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 LibreOffice bug on open.
I have also filed this for OpenOffice.org. https://issues.apache.org/ooo/show_bug.cgi?id=121499
A) It does not really work with MS Office because LibO needs the document in odf and MS Office in doc(x) --> They cleaned the docoment in the others file format that well, that it worked I guess Version 4.0.3.1 (Build ID: a67943cd4d125208f4ea7fa29439551825cfb39)@ Win 7 x64
(In reply to comment #2) > A) It does not really work with MS Office because LibO needs the document in > odf and MS Office in doc(x) --> They cleaned the docoment in the others file > format that well, that it worked I guess Version 4.0.3.1 (Build ID: > a67943cd4d125208f4ea7fa29439551825cfb39)@ Win 7 x64 Hi Florian - my apologies, I should have been a bit clearer in the bug. This applies to ODF documents only. I just verified that the bug still does reproduce this behaviour on LibreOffice 4.0.2.2 (I don't have 4.0.3).
Hi.... As you are from MS, please help me with one thing (I personally can't reproduce this): if I want to sign a odf, WORD 2010 says, that it is not a supported file-format for signing... IMHO I was not able to get the idea behind this: A signature gets deleted on saving (changing the document)... Thanks for further explanations...
(In reply to comment #4) > if I want to sign a odf, WORD 2010 says, that it is not a > supported file-format for signing... Again this is me not being specific enough, sorry. You need Word 2013 - digital signing of ODF was something we introduced first in that version. I wish I could provide you with a copy for testing but unfortunately I can't - I would be happy to perform any steps you want and attach the resulting docs or descriptions to the bug. > IMHO I was not able to get the idea behind this: A signature gets deleted on > saving (changing the document)... I don't think the signature is deleted at all - the file is actually declared corrupt and doesn't open at all.
Full-featured Office Professional Plus 2013 software for 60-day evaluation: http://technet.microsoft.com/en-us/evalcenter/jj192782.aspx
Created attachment 85605 [details] Various testcases I was very much disappointed when tried to reproduce this problem. While it is perfectly reproducible using LO 4.1 and trial version of MS Office 2013 under Win7x64, I am tempted to set it to NOTOURBUG. 1. If an ODF file is created by MS Office 2013, or if a LO OFD is edited by MSO, and even when a (previously unsigned by LO) ODF is signed by MSO, the resulting package is perfectly readable by ZIP tools like, say, 7-zip. But if a LO-signed ODF is signed by MSO, the resulting file fails to be extracted by 7-zip (but some other tools are able to extract it: changing extension to ZIP lets me open it using Windows Explorer built-in ZIP viewer without problems). Trying to find the cause for it, I used InfoZip's unzip tool with -Z switch. It shows that files inside the package have "mismatch between local and central GPF bit 11 ("UTF-8")" - you may see the scan results in the attachments' txt files. Yes, I know that the OASIS standard "Open Document Format for Office Applications (OpenDocument) Version 1.2" requires ODF packages to follow "PKWARE Inc. Zip APPNOTE Version 6.2.0", and that version didn't use the GPF bit 11 ("UTF-8"). But still I wonder, if it is really necessary to implement a distinct implementation of ZIP software (that sets some unused bits of file structures to non-zero values, which is a bad idea) just to handle special cases like signing already signed documents? 2. Then, I examined the contents of the package. The signed by LO and then signed by MSO package has an interesting directory inside it: "[trash]", with one binary file "0000.dat". That directory (and file) are absent in the original ODF signed by LO. I read the "Open Document Format for Office Applications (OpenDocument) Version 1.2" part 3: Section 3.5: >"Files within a package may have a digital signature applied. Digital signatures are stored in one or more files whose relative paths begin with “META-INF/”. The names of these files shall contain the term “signatures”." Chapter 5: >"... In particular, consumers may require that a digital signature references all files contained in a package." I suppose that it is evident that signatures in the file named "documentsignatures.xml" in "META-INF/" subdirectory apply to the whole package (document), and thus adding a new file to the signed package MUST invalidate the already applied signatures in that file. Or am I just too optimistic? 3. This may be irrelevant, but the signature file ("META-INF/documentsignatures.xml") itself is transformed dangerously. Specifically, MSO converts its line endings from UNIX-style (LF) (as it was produced by LO) to Windows-style (CR LF). But the parts of this file referenced by the LO signatures have no CanonicalizationMethod applied, so changing some bits of those parts may invalidate the signatures, too. (However, I don't know much about this, so it may be a wrong assumption.) I consider the newly-added feature in MSO potentially very important for interoperability, and this prevents me from just closing this bug. But I cannot understand some things. - Why a corporation that is a member of OASIS is unable to follow standards developed by OASIS? - Why a corporation that presumably has some experience in making software (and making money by this) cannot use its own debugging resources to catch this, and must ask community of a free and open-source competitor to debug problems in that corporation' flagship product?
Great research work Mike thanks for your thorough investigation ! :-) I think pragmatically we prolly will have to work around this in whatever way we can in our import (at some stage), as/when someone has the time to do that your work will be invaluable here I think. Confirming at least for now :-)
Hi guys - thanks for looking into this and my apologies for the oddnesses of MS Office. I am also not personally a fan of the Microsoft CR/LF thing. Mike - as the OASIS member in question, I think I'd better follow up: which part of the standard are we not following correctly? I know the GPF bit 11 issue is annoying but I think we're actually still compliant with the APPNOTE. I believe the [trash] directory is allowed to remain in the file, and I don't believe there's anything in ODF that requires invalidating existing signatures when new ones are added. I can't find anything specific in ODF about the carriage-return/line feed part, so I'm wondering if it's that? if this is our bug, we should definitely fix it in MS Office.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Dear Chris Rae [MSFT], To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Chris Rae [MSFT], To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Chris Rae [MSFT], To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug