After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 386468 - gpg encrypted message not shown
gpg encrypted message not shown
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.6.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Milan Crha
Evolution QA team
evolution[gpg]
Depends on:
Blocks:
 
 
Reported: 2006-12-16 11:44 UTC by Johannes Berg
Modified: 2009-10-16 08:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
test message (as mbox) (1.59 KB, message/rfc822)
2006-12-16 11:45 UTC, Johannes Berg
  Details
private/public key pair the message is encrypted to (3.08 KB, text/plain)
2006-12-16 11:46 UTC, Johannes Berg
  Details
proposed eds patch (2.22 KB, patch)
2009-02-04 19:11 UTC, Milan Crha
committed Details | Review

Description Johannes Berg 2006-12-16 11:44:44 UTC
Please describe the problem:
I'm going to attach a message that is encrypted to the following test key: http://johannes.sipsolutions.net/files/testkey.asc

Said message is not shown at all when viewed in evolution even though it contains some text!

Additionally, the message is signed by my key as gpg shows:

johannes:~$ gpg --decrypt /tmp/msg

You need a passphrase to unlock the secret key for
user: "Some Tester (never use this key) <testkey@example.org>"
1024-bit ELG-E key, ID B6F004FF, created 2006-12-16 (main key ID 4C6B3A42)

gpg: encrypted with 1024-bit ELG-E key, ID B6F004FF, created 2006-12-16
      "Some Tester (never use this key) <testkey@example.org>"
This is just a short test message.
gpg: Signature made Sat 16 Dec 2006 12:27:37 PM CET using DSA key ID 9AB78CA5
gpg: Good signature from "Johannes Berg <johannes@sipsolutions.net>"
gpg: [...]

But evolution claims that it is not signed!


Steps to reproduce:
1. import the secret and public key from http://johannes.sipsolutions.net/files/testkey.asc
2. import my public key 9AB78CA5 from a keyserver
3. import the message I'm going to attach
4. view the message

Actual results:
"encrypted" and lock with green check is displayed but no message contents, clicking the lock shows "not signed"

Expected results:
the message contents is displayed, the lock as well, and clicking the lock shows that it is encrypted to my key

Does this happen every time?
yes

Other information:
Comment 1 Johannes Berg 2006-12-16 11:45:47 UTC
Created attachment 78467 [details]
test message (as mbox)

this is the test message you can import
Comment 2 Johannes Berg 2006-12-16 11:46:53 UTC
Created attachment 78468 [details]
private/public key pair the message is encrypted to

this is the key pair just so that it's stored along with the bug. It'd be nice if there was a key pair publically available for the purpose of reporting bugs with encrypted mail, feel free to use this one
Comment 3 Johannes Berg 2006-12-16 12:00:00 UTC
made a separate issue out of the "claims it is not signed" in bug 386474
Comment 4 Milan Crha 2009-02-04 19:11:49 UTC
Created attachment 127938 [details] [review]
proposed eds patch

for evolution-data-server;

The reason is that the usual encrypted text begins with headers like
Content-Type and Content-Transfer-Encoding, but that yours isn't.

Actually, I'm not sure how much it is a bug or not.
Comment 5 Johannes Berg 2009-02-04 19:27:43 UTC
I would have thought

Content-Type: multipart/encrypted; boundary="=-=-="; protocol="application/pgp-encrypted"

would be enough?
Comment 6 Milan Crha 2009-02-05 10:43:21 UTC
Nono, those lines are supposed to be inside the encrypted part. When evolution itself encrypts text, it's like this (I do not have exact values handy, but very similarly like this):
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

This is a short message text.

The important part is definition of the content type of the encrypted part, so Evolution (and other clients, I guess) will know what to do with it. You know, it can be basically anything, even some image or an external document.

Ehm, which reminds me to set the content type in the patch to the application/octet-stream and mark it as inline, thus it will be shown as an attachment, but the opened one. (It doesn't worth to resend a patch, does it?)
Comment 7 Srinivasa Ragavan 2009-02-12 10:19:54 UTC
Johannes, can you test the patch, Milan provided ?
Comment 8 Milan Crha 2009-10-16 08:36:54 UTC
Created commit eaaf8dd in eds master (2.29.1+)