unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Rob Browning <rlb@defaultvalue.org>, bug-gnu-emacs@gnu.org
Cc: 745553-forwarded@bugs.debian.org, 745553@bugs.debian.org
Subject: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Date: Fri, 02 May 2014 16:29:53 -0400	[thread overview]
Message-ID: <53640041.7070703@fifthhorseman.net> (raw)
In-Reply-To: <877g6eilsp.fsf@trouble.defaultvalue.org>

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

On 04/24/2014 03:12 PM, Rob Browning wrote:
> [If possible, please preserve the 745553-forwarded address in any replies.]
> 
> This bug was filed recently, and I suspect it might be something you'd
> like to discuss upstream.

thanks for forwarding this, Rob.

More notes below:

> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
 [...]
>> Consider Alice, who has OpenPGP certificates for "Bob
>> <bob@example.org>" and "Carol <carol@example.org>" in her keyring (in
>> that order).  She has certified them both, so there is one valid
>> primary key for bob@example.org and one valid primary key for
>> alice@example.org.
>>
>> Bob turns evil (or maybe his key is compromised) and he adds a new
>> User ID: "Bob <carol@example.org>" to his OpenPGP cert.  He publishes
>> the update to the keyservers.
>>
>> Alice, following best practices, updates her keyring from the
>> keyservers regularly.
>>
>> Alice's keyring now has two certs that have a "carol@example.org" user
>> ID in them.  One of them is valid, and the other one is not.
>>
>> Alice now composes a message to "Carol <carol@example.org>" and marks
>> it with:
>>
>>  <#secure method=pgpmime mode=signencrypt>
>>
>> As the message goes out, mml-mode just passes the e-mail address
>> carol@example.org to gpg to encrypt the message body, and gpg uses the
>> e-mail address to select a key.  Since Bob's key is first in the
>> keyring, it is the one that will be used.

Turns out the situation is slightly worse than i described above.  While
i still think that mml2015-always-trust should default to nil (and this
defends against some failure modes), there are other problems with key
selection that aren't fixed yet.

In particular, the problematic scenario described above is *not* fixed
by changing the setting.  Observing the behavior, it looks like mml-mode
does OpenPGP certificate selection by e-mail address in the following
way (sorry i haven't dug into the code yet):

 0) it asks GnuPG for a cert associated with the given e-mail address

 1) it checks the *overall* validity of the cert in order to decide if
the cert is the right one

 2) if the cert is valid, it encrypts to it.

The problem with this is how gpg defines the overall validity of the
cert: in particular, it defines the validity of a cert as the *highest*
validity of any UserID associated with the cert.  It should instead be
looking at the validity of the desired User ID specifically, not the
overall cert.

So in the scenario above, Bob's cert is still overall valid (because it
has a valid certification over the correct UserID+key from Alice), even
though the carol@example.org UserID is invalid.

I don't know mml-mode or elisp well enough to dig into the code and fix
this part of the problem quickly, but if someone has patches that i can
look at that would point to where it might be changed, i'd be happy to
try to review them.

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1010 bytes --]

  reply	other threads:[~2014-05-02 20:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140422190613.18043.21415.reportbug@alice.fifthhorseman.net>
2014-04-24 19:12 ` Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t Rob Browning
2014-05-02 20:29   ` Daniel Kahn Gillmor [this message]
2017-01-25 17:19     ` bug#17391: " Lars Ingebrigtsen
2017-01-25 20:09       ` bug#17338: " Jens Lechtenboerger
2017-01-25 20:30         ` Daniel Kahn Gillmor
2017-01-26 18:36           ` Jens Lechtenboerger
2017-01-26 19:34             ` Daiki Ueno
2017-01-26 23:17               ` bug#17338: " Daniel Kahn Gillmor
2017-01-27  2:49                 ` Daiki Ueno
2017-01-27  2:49                 ` bug#17338: " Daiki Ueno
2017-01-26 23:13             ` Daniel Kahn Gillmor
2017-01-27  6:45               ` Jens Lechtenboerger
2017-01-26 23:19         ` Daniel Kahn Gillmor
2022-02-20 13:11         ` bug#17338: " Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53640041.7070703@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=745553-forwarded@bugs.debian.org \
    --cc=745553@bugs.debian.org \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=rlb@defaultvalue.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).