Issue 85306

Summary: signing a document macro seems to be broken
Product: General Reporter: Oliver Brinzing <oliver.brinzing>
Component: codeAssignee: h.ilter
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P2 CC: cno, frank.schoenheit, issues, joachim.lingner, joerg.skottke, Mathias_Bauer, mikhail.voytenko
Version: OOo 2.3.1Keywords: regression
Target Milestone: OOo 3.2   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 76318    
Description Flags
signing a document macro seems to be broken
A document with signed macro. none

Description Oliver Brinzing 2008-01-16 17:49:21 UTC

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

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

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

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.

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