Issue 85306

Created attachment 50916 [details]
signing a document macro seems to be broken

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

@ jsk: Please have a look. Do you also think it's a 2.4 blocker? Please set target.

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

to fst: i don't have any working environment for this (no signature)

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

JL->MAV: Please take over.

*** Issue 81082 has been marked as a duplicate of this issue. ***

Created attachment 54759 [details]
A document with signed macro.

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.

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

.

@ab: setting target to 3.1 as discussed.

Cannot be fixed for 3.1 any more -> 3.2

-> OOo 3.3

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.

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?

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.

Thanks, so the comment was misleading.

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

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

Right, that was the comment I referred to in my question.
Sorry for the confusion.

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.

Setting to fixed, since the scenario is already fixed in encsig09.

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.

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

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.

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.

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() ?

mav->mba: The issue 104876 is the follow-up issue.

Verified with cws encsig09 = It is fixed for the new ODF 1.2
See also i103989

Exactly, while storing ODF1.1 document to ODF1.2 format, the macro signature is
not preserved since it is not allowed.