Description of problem:
this is actually not a RedHat/Fedora bug, it's an Evolution issue but the GNOME bugzilla doesn't seem to support reporting security/private bugs so Milan asked me to report here.
When selecting the key for GPG-encrypted mail, Evolution seems to do:
gpg --encrypt -r firstname.lastname@example.org
This is actually a bad idea, because it matches every userid including email@example.com (wether in the first or last name, in the comment or in the email address).
What makes it worse is that gpg returns the first match, so in case something else matches the email address given (for example firstname.lastname@example.org instead of email@example.com), then the mail will be encrypted to the *wrong* recipient. This looks like a security issue to me, thus marking it as such and reporting it. If you disagree, feel free to change that.
In the gpg manpage there's an explanation about how userid can be selected, and for example:
By exact match on an email address.
This is indicated by enclosing the email address in the usual
way with left and right angles.
So the angles should be added to the command line used by Evolution.
Note that this still won't work if multiple keys match that email address. Maybe Evolution should do the same as mutt, which seems to first search (using I guess gpg --list) the keys matching a query, then ask the user to select the uid. This would make sure the user actually knows to what recipient the mail is encrypted to.
And also note that, right now, there's no way to encrypt the mail to the correct recipient but to delete the key from the keyring.
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. create keys for multiple recipient with matching email addresses (firstname.lastname@example.org and email@example.com)
2. try to write gpg encrypted mail to both addresses
Mail is always encrypted to the first matching user id.
I fixed the bracketing issue upstream in time for E-D-S 3.9.5 and 3.8.4:
The multiple match issue is something I'll be more willing to deal with once I port Camel to use GPGME instead of parsing raw gpg console output over pipes.
Since this is now public per commit to the repository, I'll request a CVE from oss-sec.
I'm going to turn this into an SRT bug so this can be properly tracked.
Do we know when this was introduced? Or has Evolution since forever had this issue?
Created evolution tracking bugs for this issue:
Affects: fedora-all [bug 987108]
(In reply to Vincent Danen from comment #5)
> Do we know when this was introduced? Or has Evolution since forever had
> this issue?
It's present in the 1.5 releases from 2004. That's as far back as I checked. So effectively it's been there forever.
This was assigned CVE-2013-4166 as per http://seclists.org/oss-sec/2013/q3/191
This issue has been addressed in following products:
Red Hat Enterprise Linux 6
Via RHSA-2013:1540 https://rhn.redhat.com/errata/RHSA-2013-1540.html
Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Low security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.