GNOME Bugzilla – Bug 313806
gw: cannot decrypt an encrypted message
Last modified: 2013-09-13 00:46:49 UTC
Version details: 2.3.7 Distribution/Version: SuSE 9.3 Receive an encrypted message. Now try to access the message Actual results: It does not prompt for the passphrase and in the message it says "Could not parse S/MIME message. gpg: armor header: Version: GnuPG v1.4.0 (GNU/Linux) gpg: public key is BA7EAA58 gpg: using secondary key BA7EAA58 instead of primary key D07575BC gpg: encrypted with 1024-bit ELG-E key, ID BA7EAA58, created 2005-06-21 "Shilpa C <cshilpa@novell.com>" gpg: decryption failed: secret key not available" Expected results: Should prompt for the passphrase as soon as the encrypted message is selected. Should decrypt the message if the correct passphrase is entered. Otherwise should display the above message if the wrong passphrase or the passphrase is not entered. Other information: Using the IMAP protocol to send and receive the message and using PGP encryption.
If an encrypted message is sent using groupwise, the message is received as an attachment which says 'PGP/MIME-encrypted message header attachment'
Umm, this means you dont have the key to decrypt the message. You cannot be asked for a passphrase on a non-existant key. gpg: encrypted with 1024-bit ELG-E key, ID BA7EAA58, created 2005-06-21 "Shilpa C <cshilpa@novell.com>" gpg: decryption failed: secret key not available" The second comment looks like a bug somewhere though.
Reassigning to Partha as it looks like a Groupwise bug. In imap this works just fine
Created attachment 50976 [details] [review] Patch for the bug The groupwise soap interface expects the signature (any attachment) to be in base64. The attached patch fixes that.
you do know that, because of a particularly stupid rfc (rfc1847), that multipart/signed and multipart/encrypted MUST be treated as a completely opaque, basically binary, block? You can't process it in separated parts. (i'm not sure from that patch if that's what you do, but it looks like you do).
The groupwise server soap interface (unfortunately) expects it as an attachment with some particular name. Sigh! have to change a lot in this patch. for 2.4.1 maybe.
This bug has been fixed on HEAD. Cant commit the patch to the stable branch since it will break API/ABI. Closing this bug.