Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||signing a document macro seems to be broken|
|Product:||General||Reporter:||Oliver Brinzing <oliver.brinzing>|
|Status:||CLOSED FIXED||QA Contact:||issues@framework <issues>|
|Priority:||P2||CC:||cno, frank.schoenheit, issues, joachim.lingner, joerg.skottke, Mathias_Bauer, mikhail.voytenko|
|Target Milestone:||OOo 3.2|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
Description Oliver Brinzing 2008-01-16 17:49:21 UTC
Hi, - set macro security to "high" - sign a document macro (-> tools/macros/digital signatures) - close the document - open the document and edit something (do *not* edit the macro itself) - save document - open the document again -> macro's are disabled now ... :-( Oliver
Comment 1 Oliver Brinzing 2008-01-16 17:50:14 UTC
Created attachment 50916 [details] signing a document macro seems to be broken
Comment 2 Frank Schönheit 2008-01-16 18:10:46 UTC
I can confirm this. You do not even need to fiddle with the macro security. Just - sign the document's macros - save, close and re-open the document => verify the document macros' signatures are intact - modify the document - save, close and re-open the document => the signatures of the document macro are broken The bug is present in OOo 2.3 already, but not in 2.2.1. I'm tempted to consider this a 2.4 blocker ...
Comment 3 Olaf Felka 2008-01-17 07:09:20 UTC
@ jsk: Please have a look. Do you also think it's a 2.4 blocker? Please set target.
Comment 4 Oliver Brinzing 2008-01-17 09:42:11 UTC
Hi, just noticed: if i open a signed macro document (macro security is "high") and change the macro itself, signing get's lost, but macro execution is still possible as long as the document is open ... is this another bug ? BTW: is there a change to execute only macro's which have been signed by a special trust center/company key ? In this case it should not be possible for users to add signatures ... Oliver
Comment 5 joerg.skottke 2008-06-17 11:45:22 UTC
to fst: i don't have any working environment for this (no signature)
Comment 6 frank 2008-06-17 13:47:33 UTC
Hi Jochen, did we change something here in handling of Signatures for Macros? They are stripped out on save of the document if something is altered. It's the same for 2.4.1 and 3.0 . If it's not your construction site, re-assign please. Frank
Comment 7 joachim.lingner 2008-06-23 12:32:04 UTC
JL->MAV: Please take over.
Comment 8 joachim.lingner 2008-06-23 12:53:30 UTC
*** Issue 81082 has been marked as a duplicate of this issue. ***
Comment 9 mikhail.voytenko 2008-06-26 12:09:43 UTC
Created attachment 54759 [details] A document with signed macro.
Comment 10 mikhail.voytenko 2008-06-26 12:19:10 UTC
mav->ab: The first attached document has no macro-signature at all. I have attached another document with signed macro. The problem with the second document is that the BasicManager behaves as modified one ( SfxBasicManagerHolder::isAnyContainerModified() returns true ). As we have discussed there was already a bug that this method returned true, because a document without dialog libraries had always got Â¨StandardÂ¨ library, and the DialogContainer was modified then. But this time the BasicContainer is modified, although I have only opened a document and saved it ( Save operation ). Could you please take a look.
Comment 11 ab 2008-07-03 13:25:15 UTC
It's a similar mechanism. The document does not contain Basic macros. But while beeing asked hasBasic() the Standard library is beeing created by the way. As the coded used for this is not only used in this scope I think it's risky to touch this now. I also don't consider this to be a showstopper, as this is a long known problem and as it only occurs for documents containing signed script but no Basic scripts. -> STARTED, 3.x
Comment 12 joachim.lingner 2008-07-07 10:26:34 UTC
Comment 13 joachim.lingner 2008-07-07 10:33:09 UTC
@ab: setting target to 3.1 as discussed.
Comment 14 ab 2009-01-21 08:41:04 UTC
Cannot be fixed for 3.1 any more -> 3.2
Comment 15 ab 2009-09-07 16:38:24 UTC
-> OOo 3.3
Comment 16 bwiedemann 2009-09-07 17:28:26 UTC
This is sad. The feature is good, but it is broken since 20 months and will be defect for another year (?). So why not put it out, if it is defect and will not be fixed? This would be honest at least. Keeping it in defect seems like a bad idea to me.
Comment 17 Mathias_Bauer 2009-09-07 18:53:36 UTC
I'm a bit confused; ab wrote that the bug only applies to documents containing signed scripts, not to documents containing signed basic macros. The disappointment in the last comment let's me think that this isn't true. Right?
Comment 18 Frank Schönheit 2009-09-07 19:17:02 UTC
fs->mba: No, this doesn't apply to scripts only, but to basic macros: If you have a document where you sign the macros (not the document content), then close/re-open/modify/save/close this document, then the macro signatures are lost.
Comment 19 Mathias_Bauer 2009-09-07 19:43:52 UTC
Thanks, so the comment was misleading.
Comment 20 cno 2009-09-07 20:23:31 UTC
@mba: "so the comment was misleading" Yes, bit if I understand it correct, it is the comment from ab (desc12, 2nd par.) that is misleading.
Comment 21 cno 2009-09-07 20:23:39 UTC
@mba: "so the comment was misleading" Yes, but if I understand it correct, it is the comment from ab (desc12, 2nd par.) that is misleading.
Comment 22 Mathias_Bauer 2009-09-08 07:27:19 UTC
Right, that was the comment I referred to in my question. Sorry for the confusion.
Comment 23 mikhail.voytenko 2009-09-08 07:39:20 UTC
The problem should be now workarounded in cws encsig09. The check is not done any more, instead the signature is always checked on storing. This workaround of course affects the performance ( only in case a document with signed macros is stored, normal documents are not affected ), but while deciding between performance and correctness the correctness should win. Changing the title accordingly. The fix for the mentioned problem is still important to have the mentioned above optimization. A successor issue 104876 is opened for this. Taking this issue over.
Comment 24 mikhail.voytenko 2009-09-08 08:27:23 UTC
Setting to fixed, since the scenario is already fixed in encsig09.
Comment 25 mikhail.voytenko 2009-09-08 08:33:08 UTC
mav->hi: Please verify that the scenario works well in encsig09. The first attached document seems to contain no signature at all, please use the document "signedmacro.odt" for testing. Please remember that the document is ODF1.1 document, that means that the macro signature will be transfered only in case the office stores ODF1.1. If the office stores ODF1.1 document as ODF1.2 one, the signatures are not allowed to be transfered.
Comment 26 ab 2009-09-08 10:19:13 UTC
Now I'm really confused, especially because of fs's comment (desc19). If the problem also applies to Basic macros I don't think that it is really covered by this issue. mav send this issue to me with an attached sample document and in his comment (desc11) he described that the BasicContainer gets modi- fied without really being modified. mav's sample document doesn't contain any Basic and I found that Basic gets modified because the Standard library is created internally when hasBasic() is called. So my comment (desc12) isn't misleading, it just describes the only problem that is covered by mav's comment and sample. And this pro- blem indeed only occurs for documents containing signed scripts but no Basic scripts (which by the way could easily be worked around by just adding an empty Basic library). That was and still is my level of knowledge concerning this problem and nobody had objected until now. So I wonder what exactly is cove- red by cws encsig09 and what the successor issue 104876 is about. If also documents containing Basic are affected there must be ano- ther completely different bug mechanism that hasn't been visible for me so far. I also need another sample document then for i104876. Can anyone please help me to reduce my confusion... :-)
Comment 27 Frank Schönheit 2009-09-08 10:48:02 UTC
fs->ab: see my very first comment at the top of the issue, this describes how you can reproduce this with Basic macros. It is basically the same description as Oliver's original one, except that you don't need to fiddly with macro security.
Comment 28 mikhail.voytenko 2009-09-08 11:37:26 UTC
mav->ab: The cws encsig09 contains the reimplementation of the functionality. In the new implementation the macros signature should be successfully transported independently from whether there are basic scripts or not. The successor issue 104876 contains from my point of view a clear description, at least it is clear enough to not to ask "What is it about?" and to ask a concrete question related to the description. The issue is regarding the functionality provided by the SfxBasicManagerHolder::isAnyContainerModified() method implementation. The implementation does not work always as designed, in other words the method returns "true" even if the scrips were not modified. The relation to this issue is that if the method would work reliably, it would allow to optimize storing of documents with macro signatures.
Comment 29 Mathias_Bauer 2009-09-08 12:39:34 UTC
Thanks for caring! I agree that the small performance loss is an acceptable price to pay for getting this fixed. Do we have a follow-up issue or do we accept the current behavior of SfxBasicManagerHolder::isAnyContainerModified() ?
Comment 30 mikhail.voytenko 2009-09-08 13:24:35 UTC
mav->mba: The issue 104876 is the follow-up issue.
Comment 31 h.ilter 2009-09-10 09:31:51 UTC
Verified with cws encsig09 = It is fixed for the new ODF 1.2 See also i103989
Comment 32 mikhail.voytenko 2009-09-10 09:42:26 UTC
Exactly, while storing ODF1.1 document to ODF1.2 format, the macro signature is not preserved since it is not allowed.