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 331361 - Allow GPG decryption with anonymous recipient set
Allow GPG decryption with anonymous recipient set
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.4.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Milan Crha
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-02-16 03:21 UTC by Jacob Appelbaum
Modified: 2011-12-19 10:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
proposed eds patch (2.83 KB, patch)
2009-12-22 14:10 UTC, Milan Crha
committed Details | Review

Description Jacob Appelbaum 2006-02-16 03:21:19 UTC
Please describe the problem:
I use a private mailing list [0] that has an interesting feature set. To use the
list you must have the lists gpg (public) key. You send an encrypted email to
the list, the list server verifies your signature and decrypts the messsage. As
far as evolution is concerned, this works perfectly fine. 

The server then consults to see who should get the message and encrypts it to
everyone on the list. This is useful because only the server admin needs to keep
the user keys updated, I do not need to know their key. I trust the server admin
in this threat model. It's not perfect but it works.

When the message is sent to everyone on the list, the list has the option of
throwing the key-id[1]. If the message has the key-id thrown, the message is
effectively anonymous. No key-id seems

Here is how you can simulate the mailing servers type of anonymous message:
gpg -e -a --throw-keyid -r jacob@appelbaum.net

To see what it looks like when such a message is piped to gpg:
 gpg -e -a --throw-keyid -r jacob@appelbaum.net |gpg
dsak
gpg: anonymous recipient; trying secret key XXXXXXX ...
Enter passphrase:

You can also generate this type of message like so:
gpg -a -e -R jacob@appelbaum.net

Any message you encrypt will be blind to gpg or anyone else trying to find the
recipient. When gpg gets the message, it does not have a key-id and thus has to
try each of your secret keys until it finds the correct one. This becomes a
problem when you have multiple gpg keys and multiple email addresses.

It appears that evolution has several issues when dealing with these types of
messages.



[0] http://codecoop.org/projects/firma/
[1] http://lists.gnupg.org/pipermail/gnupg-devel/1998-August/014415.html

Steps to reproduce:
1. Create an encrypted gpg message with a stripped key-id: gpg -e -a
--throw-keyid -r jacob@appelbaum.net

2. Make the proper mime headers so that evolution will attempt to decrypt the
message when the user opens the email.

(alternatively, setup a firma list [0])

3. The user must have more than one gpg key. (I have four, one per email address
that's different)

4. The user will be prompted for their passphrase, evolution selects the first
key in the key ring. It cycles through all of the different secret keys, even
the correct one. It doesn't appear that evolution ever understands when you've
typed the correct passphrase for the correct key. It never knows which key is
the correct one as far as I can tell.


[0] http://codecoop.org/projects/firma/

Actual results:
Evolution reports:
"Could not parse S/MIME message
Failed to unlock secret key: 3 bad passphrases given."

Expected results:
I expect evolution to detect if the message is anonymous or not. It should
behave differently when it detects a stripped key-id. In the case of a stripped
key-id, I would like evolution to request the passphrase of each key and have it
try all of the keys, not just three of them as it seems to do now. I assume this
is because of the threshhold of incorrect keys is three tries. This doesn't work
if you have four keys. It might not work if you only have one key. In my
experience, the correct key can be the third one as far as I can tell, it still
will not decrypt. I assume evolution has some sort of wrapper around gpg that
fails when it sees this type of message.

Does this happen every time?
Yes.

Other information:
<ioerror> I think I've found a bug in the way that evolution handles gpg
encrypted messages that are anonymously encrypted (Evolution 2.4.1 in ubuntu)
<guenther> hehe
<guenther> What is "anonymously encrypted"?
<ioerror> gpg has an option to blindly encrypt a message
<ioerror> This seems to confuse evolution if you have a weird setup
<ioerror> I have four secret keys for four different email addresses
<guenther> ioerror: I still don't get it... What does this do?
<guenther> which option?
<ioerror> let me dig it up, brb
<ioerror> http://lists.gnupg.org/pipermail/gnupg-devel/1998-August/014415.html
<ioerror> I think that was the first time such a feature was introduced
<guenther> oh
<ioerror> example: 
<ioerror>  gpg -e -a --throw-keyid -r jacob@appelbaum.net
<guenther> Right, and now Evo does not know which key to use, eh?
<ioerror> when I get an email to that address, evo says: "give me your key for
secret key number 1"
<ioerror> and it tries three keys in a row, it never makes it to the fourth one
<ioerror> which in my case is the correct key
<ioerror> As such, I can never read these messages in evolution.
<guenther> ioerror: Please file a bug in bugzilla, giving as much details as
possible.
<ioerror> Unless I missed, it could be fixed by setting a higher threshold of
passwords to allo
<guenther> oh, you can -- change the key order in your private keyring ;-)
<ioerror> Sure, i can file a bug, where's the link to the bugzilla?
<guenther> bugzilla.gnome.org
<ioerror> Well, that's useless in this case, I have four email addresses all
using similar thrown-key lists
<guenther> of course
<ioerror> no matter the order, i will always trip this bug unless I'm just
totally missing something
<ioerror> I imagine there's two other people in the world that even care about
this feature though
<guenther> yeah...
<guenther> I guess the solution is not to raise the threshold.
<ioerror> I am however talking to them with this list and so, I care ;-). I'm
going to go file a bug now. Thanks for your time guenther, you've been helpful
<guenther> But to make Evo realize, it needs to test all keys... Or ask which
one to use.
<ioerror> yeah
<ioerror> I have key ids set for each address
<guenther> letting the user choose (if possible here, dunno) would be good
<ioerror> I suspect that evolution could say: "I see you have a default key for
the address this was sent to, lets try that first, then do the next key in the
order"
<guenther> failing that, at least detecting that it is "anonymous", so it can
alter the full list at least
<ioerror> Then ask for passphrase for the next key until there are no more keys
to try.
<ioerror> yeah
<guenther> mention *all* this :)
<guenther> Please provide as much details, as possible.
<ioerror> I'm just going to paste this chat likely and then explain the software
i'm using
<guenther> eh...
<guenther> Whatever... I'd explain it, though.
<guenther> ioerror: Out of curiosity -- Why are you using this?
<guenther> I mean... The goal is to not "brand" the encrypted data stream with
the key id.
<ioerror> I am using an encrypted mailing list.
<ioerror> The list has an option for blind encryption, so you don't know who the
message is encrypted to
<guenther> But since the message is delivered via the internet, the envelope
shows the addressee in cleartext.
<ioerror> ie: I don't know who else is on the list
<ioerror> the software scrubs all the info, it's a remailer
<-- ratschnowski has quit (... je me casse, a+)
<guenther> uhm...
<guenther> aha
<ioerror> I only know that once I've decrypted the message, I have plaintext
from the sender, signed and verified
<guenther> This is weird, dude. :)
<ioerror> anyone else watching is going to get a message from a server list that
is blindly encrypted
<ioerror> Make sense?
<guenther> it does
<guenther> it still is weird
<ioerror> Good times.
<guenther> :)
Comment 1 Milan Crha 2009-12-22 14:10:51 UTC
Created attachment 150230 [details] [review]
proposed eds patch

for evolution-data-server;

Not as that big change. Are you able to give it a try, please? I tried few things and it seems to work fine, I'm asked for a password of "each" of my private key and then gpg tries one after each other. (actually it isn't each, as gpg picks only some of them.) Nonetheless, one can give it a wrong password and it'll survive. It also prints a hint about anonymous recipient in the password prompt, thus user is notified what's going on.
Comment 2 André Klapper 2011-12-17 17:15:19 UTC
Milan: Does this (your) patch still make sense?
Comment 3 Milan Crha 2011-12-19 10:14:44 UTC
Ah, right, I forgot of this completely; mostly waiting for a testing, but yes, let's commit this.

Created commit fa863a5 in eds master (3.3.3+)