GNOME Bugzilla – Bug 314333
Reply to an inline-PGP encrypted email does not decrypt orig email in body
Last modified: 2009-10-15 12:27:39 UTC
Please describe the problem: When replying to an inline-PGP encrypted email, the original email that is included in the body of the reply is encrypted. No recipient of the reply will be able to decrypt that portion of the body, making it useless. Steps to reproduce: 1. Receive an inline-PGP encrypted email 2. Hit Reply or Reply-All 3. Actual results: Original email is embedded in the reply body as encrypted text Expected results: Original email is embedded in the reply body as decrypted text. The decrypted text could be re-encrypted when the reply is sent if the user chooses to encrypt the reply. Does this happen every time? Yes Other information:
confirming, also saw this yesterday. hmm. i also commented this on bug 217540, which was the bug for inline-pgp support.
Just to confirm, you are definitely seeing this in a version of evolution that contains inline PGP support? ie > 2.3.8 I believe. If so then I'll take a look at this.
this might be fixed just after 2.3.8, i moved the inline pgp handling stuff from em-format-html, which replying doesn't use, to em-format, which is used by em-format-quote, which replying does use. if that makes sense. an easy workaround: select the text you want to reply to, and hit reply, it will use the displayed text directly.
the workaround of course works, but it isn't fixed in evolution-2.4.0.0.200508300318-0.snap.novell.11.1 will check this in a few days again
this is not fixed in evolution-2.4.0.0.200509090712-0.snap.novell.11.1, so reopening
*** Bug 326565 has been marked as a duplicate of this bug. ***
*** Bug 343478 has been marked as a duplicate of this bug. ***
I submitted a feature request relating to Evolution+GnuPG but got linked to this similar bug. I propose that the original message that is being replied too be decrypted, embedded into the new email and the new email encrypted by default, thus keeping the original message and the reply secure. This could be hard-coded in or made an option for the user. It would prevent users from accidentally sending an unencrypted reply to an encrypted email, exposing the original message.
postmodern: sorry, i obviously marked the wrong bug as original.
Still an issue in Debian evolution 2.22.1.1-1. IMO replying to an encrypted email with an unencrypted one is a bug rather than a feature. This happens with both inline-gpg and normal gpg. Debian bug is here: http://bugs.debian.org/335573
Created attachment 127930 [details] [review] proposed evo patch for evolution; This is for the issue of not setting composer's security options. With respect to the inline signatures/encryptions, I checked that and it works fine when the encrypted part has set right Content-Type, which is supposed to be application/x-inlinepgp-encrypted, respectively application/x-inlinepgp-signed In case of the inlined encrypted message being just part of some text/plain part, it's treated as that. Can you check with your message source, what is the reason? (My version is actual trunk, thus 2.25.90.)
Question about your patch: +static void +emu_update_composers_security (EMsgComposer *composer, guint32 validity_found) +{ + GtkToggleAction *action; + + g_return_if_fail (composer != NULL); + + if (validity_found & EM_FORMAT_VALIDITY_FOUND_SIGNED) { + action = GTK_TOGGLE_ACTION (E_COMPOSER_ACTION_PGP_SIGN (composer)); + gtk_toggle_action_set_active (action, TRUE); + } + + if (validity_found & EM_FORMAT_VALIDITY_FOUND_ENCRYPTED) { + action = GTK_TOGGLE_ACTION (E_COMPOSER_ACTION_PGP_ENCRYPT (composer)); + gtk_toggle_action_set_active (action, TRUE); + } +} + ... +static void +add_validity_found (EMFormat *emf, CamelCipherValidity *valid) +{ + g_return_if_fail (emf != NULL); + + if (!valid) + return; + + if (valid->sign.status != CAMEL_CIPHER_VALIDITY_SIGN_NONE) + emf->validity_found |= EM_FORMAT_VALIDITY_FOUND_SIGNED; + + if (valid->encrypt.status != CAMEL_CIPHER_VALIDITY_ENCRYPT_NONE) + emf->validity_found |= EM_FORMAT_VALIDITY_FOUND_ENCRYPTED; +} + Do the CAMEL_CIPHER_VALIDITY flags imply PGP encryption? What if the message uses S/MIME encryption? Will replying to an S/MIME encrypted message set PGP encryption rather than S/MIME encryption in the reply?
It doesn't indicate type of the found signature/encryption. It always uses GPG. Same as composer itself.
Well, the composer can use either GPG or S/MIME. There's items for both under the Security menu.
Yup, but it isn't. e-msg-composer.c:handle_multipart_signed: /* FIXME: make sure this isn't an s/mime signed part?? */ and similar in handle_multipart_encrypted :)
Created attachment 127940 [details] [review] proposed evo patch ][ for evolution; pretty simple, actually :)
I assume Matt is reviewing it.
Hi srag, I assume Matt is busy enough with kill-bonobo. What about reclassify?
Matt, would you be able to review patch now ?
Created commit 13651b3 in evo master (2.29.1+) I chose to commit to master only, as this is no a critical issue (based on number of duplicates).