This is a security bug in Emacs' mml mode when composing encrypted mail. The flaw allows an attacker to potentially trigger selection of the wrong key, and to evade a warning from gpg. Here's the situation: I'm composing a mesage in emacs in mml-mode (using notmuch, fwiw, though i don't think that matters here), and i want to send it encrypted. I use mml-secure-message-encrypt-pgpmime (via C-c RET c p) to encrypt the message. I have two friends, Alice and Bob, who have OpenPGP certificates that look like this: pub rsa4096 2016-06-02 [SC] 80213BD8FF27C90997B9F87215EA6D25570092DE uid [ unknown] Alice uid [ full ] Alice sub rsa4096 2016-06-02 [E] pub rsa4096 2016-08-16 [SC] F3CCEF926FE16622B7050F0804AEEB8BE699F289 uid [ unknown] Bob sub rsa4096 2016-08-16 [E] These are the only certs in my keyring other than my own. Note that i've managed to certify Alice's example.com User ID, but not her example.org User ID (she probably added that User ID after i checked signatures). When the mail is addressed only to bob@example.net, i get this warning when sending; if i answer "n" then the message doesn't go out: Untrusted key 04AEEB8BE699F289 Bob . Use anyway? (y or n) When the mail is addressed only to alice@example.com, i get no such warning, the message is just signed, encrypted, and sent. So far, so good :) However, when i send mail to alice@example.org, i *also* get no warning, despite the fact that the alice@example.org User ID has the same level of calculated validity as the bob@example.net User ID. This points to a nitpick and a real underlying problem, both related. Nitpick first: * The message "Untrusted key" warning message is misleading, since this has nothing to do with GnuPG's concept of "trust", or of the key. Instead, it should be looking at the validity of the binding between the User ID and the key. So the message should say something like: Unknown validity of key 04AEEB8BE699F289 for 'Bob '. Use anyway? And the real problem: * it looks like mml is actually basing its decision about the warning on the *maximum* validity of all User IDs on the certificate as a whole, rather than on the validity of the User ID that it cares about. This is a security flaw. Consider the situation above, but where Alice decides she wants to be able to read Bob's encrypted mail. If she were to add a new User ID to her OpenPGP certificate that was "bob@example.net", and i imported that cert into my keyring (e.g. while doing regular refreshes from the keyserver) then future messages that i encrypt to Bob would *not* have the warning, and would be encrypted to the wrong key. So mml is not testing the right information reported by gpg when it makes this decision. --dkg In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.5) of 2016-12-18 on x86-ubc-01, modified by Debian Windowing system distributor `The X.Org Foundation', version 11.0.11900000 System Description: Debian GNU/Linux testing (stretch) Configured using: `configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs24-aUhNHM/emacs24-24.5+1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-PIE' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-z,relro -no-pie'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix