Forward inline an encrypted message base64-encodes attachments twice

VERIFIED FIXED in mozilla1.3alpha

Status

VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: kaie, Assigned: bugzilla)

Tracking

Other Branch
mozilla1.3alpha

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Prepare your environemnt for S/Mime encryption.
Compose a new message and choose to encrypt it (but not sign it, for simplicity).
Attach a binary file to the message, like an image.
Send the message to yourself.
Receive the message.
Choose to forward inline.
Turn off encryption and signing.
Send the message to yourself.
Receive the message.

Expected behaviour: The attachments should display correctly.

Actual behaviour: The attachments are broken.


I looked into this a bit more already. What actually happens is that the
incoming message contains the attachments, but they were base64 encoded twice.

If I manually access the message source, and copy an attachment to a file, and
can get to the file by running base64-decode tools twice on it.


The intention of this bug is that we prevent encoding base64 twice when not
necessary.
(Reporter)

Comment 1

16 years ago
Note that this bug is unrelated to the upcoming fix to bug 161488. The behaviour
is the same, regardless whether you use the fix for bug 161488 or not.
(Assignee)

Comment 2

16 years ago
Does signing the forwarded message is a requirement?
(Reporter)

Comment 3

16 years ago
It does not matter whether you sign or not, and it does not matter whether you
encrypt or not.

If the initial message was encrypted, had attachments, and you forward inline,
all four combinations
  - not sign, not encrypt
  - sign, not encrypt
  - not sign, encrypt
  - sign, encrypt

produce the incorrect message as described in this bug.
(Assignee)

Comment 4

16 years ago
The image extracted from the original message and saved in the temp directory is
not decoded for some reason! Something wrong in mimedrft.cpp...
Status: NEW → ASSIGNED
(Assignee)

Comment 5

16 years ago
the problem is caused by the line
http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimedrft.cpp#1968

mdd->options->decrypt_p is true therefore we by-pass the decoding! I need to
figure out why we do that test...
(Assignee)

Comment 6

16 years ago
reassign to myself
Assignee: kaie → ducarroz
Status: ASSIGNED → NEW
Whiteboard: have fix
(Assignee)

Comment 7

16 years ago
Created attachment 105873 [details] [diff] [review]
Proposed fix, v1

This line of code comes from 4.x. Things were little bit different at that
time. I could not find any good reason to haveit anymore in MOzilla! I remove
the test of decrypt_p and everything works well now. I tested a lot of scenario
and cannot find any problem.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → 1.3
(Reporter)

Comment 8

16 years ago
Comment on attachment 105873 [details] [diff] [review]
Proposed fix, v1

This patch works fine for me.
r=kaie
Attachment #105873 - Flags: review+
Comment on attachment 105873 [details] [diff] [review]
Proposed fix, v1

sr=sspitzer
Attachment #105873 - Flags: superreview+
(Assignee)

Comment 10

16 years ago
Fixed in the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 11

16 years ago
20021203 Trunk Build.

Verified on Linux, Win2k.  Could not verify on OSX as I reopened bug 156958.

Comment 12

16 years ago
Verified on OSX as well.

Verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 13

16 years ago
*** Bug 190096 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core

Updated

10 years ago
Whiteboard: have fix
Target Milestone: psm1.3 → mozilla1.3alpha

Updated

9 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
QA Contact: carosendahl → s.mime
You need to log in before you can comment on or make changes to this bug.