Mailpile Importing a PGP key with multiple user ids causes strangeness

Importing a key with multiple PGP UserIDs can give results that are not desirable and which depend on the order and timing of events. The tests described were done with the current master, commit a6e9008.

Example:

Alice Mailer and Bob Mailer each set up an account on an IMAP server([email protected] and [email protected]) and clear the contents of the server.
Alice and Bob each set up Mailpile using their respective names and email addresses (Alice Mailer <[email protected]> and Bob Mailer <[email protected]>), each generating a new key, using defaults including local keychains for each pile.
Alice quits Mailpile, then uses CLI gpg to add a second userid (Alice Alterego <[email protected]>) to her existing PGP key, then runs Mailpile again.
Alice sends Bob an email with her key attached.
Bob receives the email from Alice, composes an encrypted reply (by clicking on the lock icon in the lower right, importing the key that was received from Alice, and clicking again on the lock icon), and sends the reply.
Bob starts to compose a new email to Alice, typing alice in the To window. Mailpile offers two options: Alice Alterego <[email protected]> Alice Alterego <[email protected]>

The "name" part Alice Alterego is used on both of these addresses, although the name in the PGP UserID for the [email protected] address is Alice Mailer. This is confusing to Bob, who has never heard of Alice Alterego before. The reason it happens is that when importing the key, Mailpile has added the name and the email address from the second user id to the VCard for [email protected].

mailpile> vcards --lines alice
Elapsed: 0.003s (vcards: Listed 1/1 results)

  0       version: 4.0
  3       clientpidmap: 1;urn:uuid:mp-gpg-5c17bd5b-0/D02599B2F928C31CB0C4B4A05C36AAFA391C3140
  2       clientpidmap: 991;priority
  1       clientpidmap: 990;default
  5 1.1   email: [email protected]
  4 1.1   email: [email protected]
  6 1.1   fn: Alice Alterego
  7 1.1   fn: Alice Mailer
  8 1.1   key: data:application/x-pgp-fingerprint,D02599B2F928C31CB0C4B4A05C36AAFA391C3140 (keytype=RSA, creation=2018-11-28, keysize=3072)
  9 1.1   x-gpg-mrgid: D02599B2F928C31CB0C4B4A05C36AAFA391C3140
 12 990.1 x-mailpile-history: s-PJVZRV-1
 13 990.2 x-mailpile-prefer-profile: 7775bfeae52 ([email protected])
 10       x-mailpile-rid: 7f45c17bd52

But, things come out differently if Bob sends emails to each of the Alices before receiving Alice's key. Start over with steps 1 - 3 above, then:

Bob composes and sends an email to each of the two Alice name and email addresses.
Alice Mailer replies to Bob with her key attached.
Bob receives the email from Alice, composes an encrypted reply (by clicking on the lock icon in the lower right, importing the key that was received from Alice, and clicking again on the lock icon), and sends the reply.
Bob starts to compose a new email to Alice, typing alice in the To window. Now Mailpile offers these options: Alice Mailer <[email protected]> Alice Mailer <[email protected]>

This time, the name from the first user id has been attached to both email addresses. Also, two VCards have been created instead of one, but both VCards contain both names and both email addresses, though the order is reversed:

mailpile> vcards --lines alice
Elapsed: 0.004s (vcards: Listed 2/2 results)

  0       version: 4.0
 10       clientpidmap: 1;urn:uuid:mp-gpg-5c17c327-0/D02599B2F928C31CB0C4B4A05C36AAFA391C3140
  5       clientpidmap: 991;priority
  1       clientpidmap: 990;default
  2 1.1,9 email: [email protected] (type=pref)
 11 1.1   email: [email protected]
  3 1.1,9 fn: Alice Alterego
 12 1.1   fn: Alice Mailer
 13 1.1   key: data:application/x-pgp-fingerprint,D02599B2F928C31CB0C4B4A05C36AAFA391C3140 (keytype=RSA, creation=2018-11-28, keysize=3072)
  4 990.1 kind: internal
 14 1.1   x-gpg-mrgid: D02599B2F928C31CB0C4B4A05C36AAFA391C3140
  8 990.2 x-mailpile-history: s-PJW0P8-1
  9 990.3 x-mailpile-prefer-profile: 7775bfeae52 ([email protected])
  6       x-mailpile-rid: d2b5c17c252

  0       version: 4.0
 10       clientpidmap: 1;urn:uuid:mp-gpg-5c17c327-0/D02599B2F928C31CB0C4B4A05C36AAFA391C3140
  5       clientpidmap: 991;priority
  1       clientpidmap: 990;default
  2 1.1,9 email: [email protected] (type=pref)
 11 1.1   email: [email protected]
  3 1.1,9 fn: Alice Mailer
 12 1.1   fn: Alice Alterego
 13 1.1   key: data:application/x-pgp-fingerprint,D02599B2F928C31CB0C4B4A05C36AAFA391C3140 (keytype=RSA, creation=2018-11-28, keysize=3072)
  4 990.1 kind: internal
 15 990.4 note:  (pref=None)
 14 1.1   x-gpg-mrgid: D02599B2F928C31CB0C4B4A05C36AAFA391C3140
  8 990.2 x-mailpile-history: s-PJW0MQ-0,s-PJW0U9-4
  9 990.3 x-mailpile-prefer-profile: 7775bfeae52 ([email protected])
  6       x-mailpile-rid: 3aa5c17c221

Conclusions:

Importing a PGP key with more than one User ID causes confusing behaviour.
Perhaps Mailpile should require that each VCard has exactly one email: line.

Dec 17 '18 15:12 JackDca

Honestly, I think we need to just stop creating VCards based on what we find on the user's GnuPG keychain. There's no way to do it in a sane way, since PGP keys can contain an unbounded amount of potentially hostile UIDs.

Which means we'll need to rethink a bunch of other things to do with contacts and keys.

Jan 10 '19 17:01 BjarniRunar

Agreed.

I took a quick look at this last month (before becoming distracted by some non-Mailpile stuff!). It may not be that hard to change.

One approach would be to always specify an email address whenever a key is imported from any source. A reference to the new key would be added only to the one VCard pointed to by that email address. The email address would not be obtained from the key's User ID(s). For example, if a message is being composed and the key has been found in a key search (and selected for import by the user), the email address would be the To: (or CC:) address for which the key search was performed. If a key is being imported from an Autocrypt header, the email address would be taken from the addr= attribute of the header.

This would mean ending the wholesale import of keys from the keychain that is now done when a pile is set up and on a rescan, but that feature is not important if Mailpile uses a private keychain, which IIRC is now the recommended default. If all the keys get into the private keychain via Mailpile, then Mailpile already knows about them.

Based on a quick look, the creation/update of VCards with new keys appears to always be done by calling the command mailpile.plugins.vcard_gnupg.PGPKeysImportAsVCards() with the key fingerprint as argument. VCards are then created/updated for every User ID contained in the key. So, an argument for the email address of the VCard to be created/updated would need to be added to that command and the lower level code that it calls. The code would then have to use that email address to specify the VCard instead of the User ID(s) in the key.

The mod to PGPKeysImportAsVCards() may be needed anyway to achieve full Autocrypt compliance. The Autocrypt spec sec. 2.1.1 makes it clear that the email address in the User ID is "only decorative". I read that to mean that the addr= email address may not be in the User ID so the present code would not add the key to the addr= VCard where it is needed.

When I get back to Mailpile I could look at this in more detail.

Jan 11 '19 16:01 JackDca

This is at least in part resolved by my latest merge/push: Mailpile will now only import the UIDs matching the e-mail address you were interested in when you searched for a key. So if someone uses one key with 6 different e-mails, you'll have to import it 6 times for Mailpile to see the whole picture.

The way Mailpile converts keys with multiple UIDs to vcards is still problematic, but we should see much, much less of that now.

Oct 24 '19 16:10 BjarniRunar