115209 - Forwarded signed messages must display correct information

Status: VERIFIED DUPLICATE of bug 115010

(MailNews Core :: Security: S/MIME, defect, P1)

Description

[Kai Engert [:KaiE:]]

Create a new mail message, enable to sign it, send it to yourself.
Fetch and display that message.

Make sure your mail news preferences are set to "forward as attachment".

Click on forward.
Disable signing for that new message.
Add some text to the forwarded message.
Send the message.

Fetch and display that message.

The header area displays the status that this message has been signed. But it
was not. Only the attachment had been signed.

The message display must be enhanced. The above was a simple scenario, but it
could even happen recursively.

The security information for each part of the received message must be displayed
in the scrolling message area, next to the "envelope area" of each contained
attached message. In the future this information must be active, i.e. clickable,
in order to open the same detail information that we will provide for simple
messages.

The fixed, nonscrolling header area must only give information about the
outermost message.

Comment 1

[Kai Engert [:KaiE:]]

The following has been decided.

This bug is valid. The signature status is wrong.

However, the additional request from by bug description will not implemented
initially.

I.e.: If you receive a signed message as an attachment, we will NOT give the
user a hint that the forwarded message was signed. (This could be a future
enhancement.)

Comment 2

[Stephane Saux]

kai.

Comment 3

[Kai Engert [:KaiE:]]

This bug has two parts:

1) Make sure only the outermost level of a nested multipart message is checked
for a signature. We can implement this now.

2) In a smime behaviour discussion it was suggested, when a forwarded/attached
message is opened and viewed separately, and that message includes a signature,
it  should be displayed. However, this requires that bug 120453 is fixed. I'm
adding a dependency.

Comment 4

[Kai Engert [:KaiE:]]

Attachment: Suggested fix

Comment 5

[Kai Engert [:KaiE:]]

Scott, this patch is completely within mailnews. Can you please review?

Comment 6

[Scott MacGregor]

this may sound silly but why do we care about broadcasting the nested level out
to the header sink if the header sink only cares if we are the top level?
Woudln't it be easier to just not call into the header sink unless we are at the
top level in the mime code? That saves some extra round trips between the UI
thread and the JS thread. Or is the thought that in the future the header sink
is going to care?

Comment 7

[Kai Engert [:KaiE:]]

Yes, the possibility you describe in your last sentence was my motivation for
that. I thought, it doesn't make sense to let the mime engine make the decision.
In the near future, I think we will extend this even more. Not sure if it will
be still the "header sink" or some additional class, but I want to do the
following: I want to make sure the "mime parsing" of the message is done only
one. And all meta information that we can collect during that phase is given out
to the "message sink" - for example verification info on each level, all the
nested certs, etc., in order to have that information available for display
without the need for parsing the message agagin. (I think that need for parsing
the message again made Communicator real slow when dealing with large
encrypted/signed messages.)

I think that area of the code that cares for displaying the message should make
the decision whether some information is wanted, or will not be shown to the user.

If you want to optimize, I suggest we find a way where the decision is still
being made by the message display code, not by the mime parser.

We could extend the header sink with a method to query the "max wanted mime
message" level. Right now that method returned "1". This could save us even more
time, because we could optimize the mime parser, not doing signature comparison,
verification, whatever, if the parser knows that this nested part is currently
not of interest.

Comment 8

[Kai Engert [:KaiE:]]

Scott, I have updated the patch in this bug, but it touches the same areas as
bug 115010. I decided it is simpler to merge the changes, and I will produce an
updated patch in the other bug.


*** This bug has been marked as a duplicate of 115010 ***

Comment 9

[Jean-Marc Desperrier]

I think it's a pity that the information that an attached message was signed is
currently lost.

Even if bug 120453 is fixed, the information will not be initially available,
and it will require that the user opens the attachment in an independant windows
to get any idea it was signed, which will not be a /natural/ move.

I'd like the initial proposition of Kai Engert ("The security information for
each part of the received message must be displayed in the scrolling message
area, next to the "envelope area" of each contained attached message") to be
implemented.

Would it be adequate that I open a separate RFE bug for that ?
What component would that be ? I don't feel it's really a PSM problem, more
mailnews.

Comment 10

[Stephane Saux]

The issue with including signature information in the flow of the message is
that it can be hacked.

4.X had the ability to show a "signed" icon in the message pane. It was fairly
straighforward to craft a message which showed a signed icon where there was no
such signature.

If was also very easy to inadvertently break the signature of inline replies and
forwards.

There is value in showing the signature of replied-to and forwarded messages,
but the only way this can be done in a safe way is to attach the signed object
as an attachment and validate the signature of the attachment.

Comment 11

[John Unruh]

Verified dupe.