Page MenuHome GnuPG
Create Task
Maniphest T2914

TOFU Conflict Status fd output broken
Closed, ResolvedPublic
Actions

Description

On conflict gnupg now emits weird TOFU_USER / TOFU_STATS status lines.

The user is listed four times. Even though the keys only have one user id.

9E64461EC423DF30F248147269007D816FAAA1EC is reported twice with 0 0 0 counters

Then it's reported again twice with 0 1 0 counters.

That tofu stats long is only printed once is also suprising imo but not a problem.

Attached are two test keys and two test messages, import the keys and verify
both messages to reproduce.

gpg2 --batch --status-fd 1 --verify msg2
[GNUPG:] NEWSIG
gpg: Signature made Fri 06 Jan 2017 04:02:16 PM CET
gpg: using EDDSA key 9E64461EC423DF30F248147269007D816FAAA1EC
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] SIG_ID CHSfDEa55p8+q7l+vYLVeAcdM50 2017-01-06 1483714936
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] TOFU_USER 9E64461EC423DF30F248147269007D816FAAA1EC
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 0 0 ask 0 0 0 0 1 0 0
[GNUPG:] TOFU_USER 7A0904B6950DA998020A1AD4BE41C0C3A5FF1F3C
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 1 0 ask 1483719805 1483719805 0 0 2 1 0
[GNUPG:] GOODSIG 69007D816FAAA1EC tofu_conflict@example.com
gpg: Good signature from "tofu_conflict@example.com" [undefined]
[GNUPG:] VALIDSIG 9E64461EC423DF30F248147269007D816FAAA1EC 2017-01-06 1483714936
0 4 0 22 8 00 9E64461EC423DF30F248147269007D816FAAA1EC
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] TOFU_USER 9E64461EC423DF30F248147269007D816FAAA1EC
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 0 0 ask 0 0 0 0 1 0 0
[GNUPG:] TOFU_USER 7A0904B6950DA998020A1AD4BE41C0C3A5FF1F3C
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 1 0 ask 1483719805 1483719805 0 0 2 1 0
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] TOFU_USER 9E64461EC423DF30F248147269007D816FAAA1EC
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 1 0 ask 1483719814 1483719814 0 0 2 1 0
[GNUPG:] TOFU_USER 7A0904B6950DA998020A1AD4BE41C0C3A5FF1F3C
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 1 0 ask 1483719805 1483719805 0 0 2 1 0
[GNUPG:] KEY_CONSIDERED 9E64461EC423DF30F248147269007D816FAAA1EC 0
[GNUPG:] TOFU_USER 9E64461EC423DF30F248147269007D816FAAA1EC
tofu_conflict@example.com
[GNUPG:] TOFU_STATS 0 1 0 ask 1483719814 1483719814 0 0 2 1 0
[GNUPG:] TOFU_STATS_LONG tofu_conflict@example.com: Verified 1~signature in the
past 0~seconds.%0AEncrypted 0 messages.
gpg: tofu_conflict@example.com: Verified 1 signature in the past 0 seconds.

Encrypted 0 messages.

[GNUPG:] TRUST_UNDEFINED 0 tofu
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9E64 461E C423 DF30 F248 1472 6900 7D81 6FAA A1EC

Details

Version
master

Related Objects

Event Timeline

• aheinecke added a subscriber: • aheinecke.Jan 6 2017, 5:34 PM

939_tofu-test.txt1 KBDownload

• aheinecke added projects: TOFU, gnupg, Bug Report.Jan 6 2017, 5:34 PM
• aheinecke set Version to master.
• aheinecke added a subscriber: neal.
• werner added a project: rc.Jan 6 2017, 7:06 PM
neal added a comment.Jan 14 2017, 11:31 PM

It's true that the user is listed 4 times, but this is because tofu.c:get_trust
is called four times. For instance, the first time it is called to show the
"gpg: Good signature from "tofu_conflict@example.com" [marginal]" line, and the
second time is it called to register the signature (tofu_register_signature).
This also explains why the signature count increases between the first and
second versions.

Note that each of these outputs is preceded by a KEY_CONSIDERED lined (for the
same key). Since the TOFU conflict information is per key, I'd expect an
implementation to say: Oh, there is already some conflict information for key X.
This must be a more up to date version, so I'll delete that first instead of
appending to it. Is this an unreasonable expectation?

It should be possible to change the behavior to only output the TOFU_STATS lines
if a TOFU_STATS_LONG line is also output (but I need to think about it some
more). Would this be better?

• werner added a subscriber: • werner.Jan 16 2017, 8:52 AM

KEY_CONSIDERED is orthogonal to the TOFU stats. Thus GPGME thus not evaluate it
to learn about the TOFU state.

• aheinecke added a comment.Jan 16 2017, 10:01 AM

Note that each of these outputs is preceded by a KEY_CONSIDERED lined (for the
same key). Since the TOFU conflict information is per key, I'd expect an
implementation to say: Oh, there is already some conflict information for key X.
This must be a more up to date version, so I'll delete that first instead of
appending to it. Is this an unreasonable expectation?

In my Opinion it is. There is a technical, (i guess) unintentional, reason for
the multiple outputs, they
don't convey useful information. So I would consider this Output a Bug and
implementations
working like you describe it to be a workaround for that bug.

Getting firs wrong information and later updating it with the correct
information makes implementations
more complicated and error prone and currently is not handled in GPGME.

Also in GPGME we just want to figure out the TOFU Info for all the UID's of the
key used
to check the signature. We don't want information about conflicting keys. We need
a reliable way to filter this out. So I have a patch that ignores all TOFU_USER
lines
that don't match the fingerprint of the signature but still that breaks because
the "Update"
is not handled.

neal added a comment.Jan 30 2017, 2:27 PM

To be clear the initial output is not wrong. At the time the information is
initially requested, the message has not yet been processed.

Anyway, I think I'm working on a fix so this is a non-issue.

neal added a comment.Feb 2 2017, 1:31 PM

This should be fixed in 027b81b35fe36692005b8dba22d9eb2db05e8c80.

neal added a project: Restricted Project.Feb 2 2017, 1:31 PM
neal closed this task as Resolved.Mar 17 2017, 7:39 PM

I'm marking this as resolved since I think is fixed. Please reopen if this is
not the case.

neal removed a project: Restricted Project.Mar 17 2017, 7:39 PM