Page MenuHome GnuPG
Create Task
Maniphest T2817

TOFU validity conflict not set on conflict
Closed, ResolvedPublic
Actions

Description

When two keys conflict like in T2815 their validity is not reported as
conflict but just as calculated from their history.
Even if I one binding is marked as bad this binding is also not reported with
validity conflict. So I wonder when conflict is ever reached. I would have
expected it when there is currently an unresolved conflict involving this userid.

And then maybe after marking one as bad to keep conflict while the other goes
back to the history based validity.

Example:

gpg2 --with-colons --with-tofu-info --homedir ~/arbeit/gpg4win/testconflict_bkp
-k aheinecke3@example.com

tru::7:1477396047:0
pub:q:256:22:87252BE27FF7506D:1476451113:::-:::scESC:::::ed25519::
fpr:::::::::B0C3D4105EFEB59FF6844A6F87252BE27FF7506D:
uid:q::::1476451113::A37B1BF93387A5BC6664EF6261946C4A0EA2E429::Andre Heinecke
(This is a Test key) <aheinecke3@example.com>:
tfs:1:2:11:0:ask:1477396077:1477396447:0:0:
sub:q:256:18:9D058C524AED800E:1476451113::::::e:::::cv25519:
fpr:::::::::E32F2E98B806565D1A0501D89D058C524AED800E:
pub:q:256:22:58E583B9012747A5:1477392831:::-:::scESC:::::ed25519::
fpr:::::::::535EE3A49BB8F14C1622B64358E583B9012747A5:
uid:q::::1477392831::EF99F618363C1F5971D3EEA0764D11189E1F3417::aheinecke3 for
conflic (Test key) <aheinecke3@example.com>:
tfs:1:2:2:0:ask:1477396084:1477396724:0:0:
sub:q:256:18:5552991F109C1238:1477392831::::::e:::::cv25519:
fpr:::::::::6C37575ECEFB6C4AAD7009A65552991F109C1238:

Now after marking one as bad:
(kf5) aheinecke@esus ~/a/k/s/gpgme> gpg2 --with-colons --with-tofu-info
--homedir ~/arbeit/gpg4win/testconflict -k aheinecke3@example.com

tru::7:1477396047:0
pub:q:256:22:87252BE27FF7506D:1476451113:::-:::scESC:::::ed25519::
fpr:::::::::B0C3D4105EFEB59FF6844A6F87252BE27FF7506D:
uid:q::::1476451113::A37B1BF93387A5BC6664EF6261946C4A0EA2E429::Andre Heinecke
(This is a Test key) <aheinecke3@example.com>:
tfs:1:2:11:0:ask:1477396077:1477396447:0:0:
sub:q:256:18:9D058C524AED800E:1476451113::::::e:::::cv25519:
fpr:::::::::E32F2E98B806565D1A0501D89D058C524AED800E:
pub:n:256:22:58E583B9012747A5:1477392831:::-:::scESC:::::ed25519::
fpr:::::::::535EE3A49BB8F14C1622B64358E583B9012747A5:
uid:n::::1477392831::EF99F618363C1F5971D3EEA0764D11189E1F3417::aheinecke3 for
conflic (Test key) <aheinecke3@example.com>:
tfs:1:2:2:0:bad:1477396084:1477396724:0:0:
sub:n:256:18:5552991F109C1238:1477392831::::::e:::::cv25519:
fpr:::::::::6C37575ECEFB6C4AAD7009A65552991F109C1238:

Related Objects

Event Timeline

aheinecke added projects: TOFU, gnupg, Bug Report.Oct 25 2016, 2:35 PM
aheinecke added subscribers: neal, aheinecke.
neal added a comment.Oct 30 2016, 4:01 PM

Are the two keys that you testing ultimately trusted? If so, then their
validity is good independent of their TOFU policy.

It is a bit unfortunate that the TOFU policy doesn't show this. I will try and
fix this, but it is a bit complicated because when a key's ownertrust is changed
(or a signature is added, etc.), the tofu db is not updated.

aheinecke added a comment.Oct 31 2016, 3:01 PM

No both have unknown trust.

neal added a comment.Nov 14 2016, 3:52 PM

Sorry for the delay in getting back to you on this issue. I think you mean they
have undefined trust (that's what I get here). Undefined trust means "not
enough information for calculation" (from trustdb.h).

Can you clarify what you mean by validity conflict?

neal added a subscriber: • werner.Nov 22 2016, 5:33 PM

Andre and I chatted about this issue offline, and I now understand what the
problem is. The TOFU_STATS status line (as documented in gnupg/doc/DETAILS) has
a "validity" field that is a number between 0 and 4 where 1 to 4 indicate how
confident we are that the binding is valid, and 0 means that the binding has an
unresolved conflict. The problem that Andre has observed is that this field is
not set to 0 if there is a conflict.

As a matter of fact, the validity field is never set to 0. This is completely
redundant as the same TOFU_STATS status line has a policy parameter, which is
"ask" if there is a conflict. Moreover, overloading this field in this way
causes a loss of information. Just because there is a conflict doesn't mean
that gpg shouldn't report the validity, or that the client can't made use of it.

Thus, in my opinion, the right thing to do is to simply use the <policy> field
to detect whether there is a conflict. Werner has suggested that this is wrong,
but I couldn't follow his logic. Thus, I'm adding him to the nosy list and I
hope he can clarify what he wants here.

neal mentioned this in T2815: TOFU conflict not part of GpgME's sigsum.Mar 30 2017, 7:19 PM
neal added a project: Restricted Project.Nov 30 2016, 11:44 AM

This should be fixed in: 2f27cb12e30c9f6e780354eecc3ff0039ed52c63 .

• werner closed this task as Resolved.Apr 3 2017, 10:53 PM

Time to say good bye my dear bug.