TOFU conflict not part of GpgME's sigsum
Open, NormalPublic

Description

Clarification: When I talk about tofu conflict I mean the following scenario:
User A verifies 11 Messages with Key B from User B

then the conflict is: User A verifies another message with Key C from User B.

When verifying a message with a tofu conflict gpgme returns an empty sigsum a
conflict is only detectable if you iterate over all userids of the signature and
check for "PolicyAsk". I think this is a bug.

Example:

(kf5) aheinecke@esus ~/a/k/b/g/tests> GNUPGHOME=~/arbeit/gpg4win/testconflict
./run-verify --verbose ~/arbeit/gpg4win/conflict-msg.asc
Original file name: [none]
Signature 0

status ....: Success
summary ...:
fingerprint: 535EE3A49BB8F14C1622B64358E583B9012747A5
created ...: 1477396691
expires ...: 0
validity ..: unknown
val.reason : Success
pubkey algo: 303 (EdDSA)
digest algo: 8 (SHA256)
pka address: [none]
pka trust .: n/a
other flags:
primary fpr: 535EE3A49BB8F14C1622B64358E583B9012747A5
tofu addr .: aheinecke3@example.com
  validity : 2 (little history)
  policy ..: 5 (ask)
  signcount: 2
    first..: 2016-10-25 11:48:04
    last ..: 2016-10-25 11:58:44
  encrcount: 0
    first..: none
    last ..: none
  desc ....: aheinecke3@example.com: Verified 2 signatures in the past 18

minutes, and

encrypted 0 messages.

(kf5) aheinecke@esus ~/a/k/b/g/tests> GNUPGHOME=~/arbeit/gpg4win/testconflict
gpg2 --verify ~/arbeit/gpg4win/conflict-msg.asc
gpg: WARNING: unsafe permissions on homedir
'/home/aheinecke/arbeit/gpg4win/testconflict'
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: Signature made Tue 25 Oct 2016 01:58:11 PM CEST
gpg: using EDDSA key 58E583B9012747A5
gpg: Good signature from "aheinecke3 for conflic (Test key)
<aheinecke3@example.com>" [undefined]
The email address "aheinecke3@example.com" is associated with 2 keys!
Please indicate whether this email address should be associated with key
535EE3A49BB8F14C1622B64358E583B9012747A5 or whether you think someone is
impersonating "aheinecke3@example.com".

This key's user IDs:

  aheinecke3 for conflic (Test key) <aheinecke3@example.com> (policy: ask)

Statistics for keys with the email address "aheinecke3@example.com":

  535E E3A4 9BB8 F14C 1622  B643 58E5 83B9 0127 47A5 (this key):
    Encrypted 0 messages.
    Verified 2 messages over the past 7 days.
  B0C3 D410 5EFE B59F F684  4A6F 8725 2BE2 7FF7 506D (policy: ask):
    Encrypted 0 messages.
    Verified 11 messages over the past 7 days.

Normally, an email address is associated with a single key. However,
people sometimes generate a new key if their key is too old or they think
it might be compromised. Alternatively, a new key may indicate a
man-in-the-middle attack! Before accepting this association, you should
talk to or call the person to make sure this new key is legitimate.

(G)ood, (A)ccept once, (U)nknown, (R)eject once, (B)ad?

neal added a comment.Nov 22 2016, 5:46 PM

I suspect that the problem is the same as T2817.

marcus removed neal as the assignee of this task.Aug 14 2017, 10:36 AM
marcus added a project: Stalled.