Members

  • This project does not have any members.

Watchers

  • This project does not have any watchers.

Recent Activity

Mar 30 2017

admin created rc.
Mar 30 2017, 6:42 PM

Mar 17 2017

neal removed a project from T2914: TOFU Conflict Status fd output broken: Testing.
Mar 17 2017, 7:39 PM · rc, Bug Report, gnupg, TOFU
neal closed T2914: TOFU Conflict Status fd output broken as Resolved.
Mar 17 2017, 7:39 PM · rc, Bug Report, gnupg, TOFU
neal added a comment to T2914: TOFU Conflict Status fd output broken.

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

Mar 17 2017, 7:39 PM · rc, Bug Report, gnupg, TOFU

Mar 1 2017

justus assigned T2965: WKD lookup fails due to overly specific Host: header to werner.
Mar 1 2017, 2:54 PM · Bug Report, gnupg, rc, gnupg (gpg22), dirmngr
justus closed T2965: WKD lookup fails due to overly specific Host: header as Resolved.
Mar 1 2017, 2:54 PM · Bug Report, gnupg, rc, gnupg (gpg22), dirmngr
justus added a comment to T2965: WKD lookup fails due to overly specific Host: header.

Fixed in cd32ebd152a522e362469ab969d91f8d49f28a60.

Mar 1 2017, 2:54 PM · Bug Report, gnupg, rc, gnupg (gpg22), dirmngr

Feb 17 2017

werner added projects to T2965: WKD lookup fails due to overly specific Host: header: dirmngr, rc.
Feb 17 2017, 9:48 PM · Bug Report, gnupg, rc, gnupg (gpg22), dirmngr

Feb 2 2017

neal added a comment to T2914: TOFU Conflict Status fd output broken.

This should be fixed in 027b81b35fe36692005b8dba22d9eb2db05e8c80.

Feb 2 2017, 1:31 PM · rc, Bug Report, gnupg, TOFU
neal added a project to T2914: TOFU Conflict Status fd output broken: Testing.
Feb 2 2017, 1:31 PM · rc, Bug Report, gnupg, TOFU

Jan 30 2017

neal added a comment to T2914: TOFU Conflict Status fd output broken.

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.

Jan 30 2017, 2:27 PM · rc, Bug Report, gnupg, TOFU

Jan 16 2017

aheinecke added a comment to T2914: TOFU Conflict Status fd output broken.

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.

Jan 16 2017, 10:01 AM · rc, Bug Report, gnupg, TOFU
werner added a comment to T2914: TOFU Conflict Status fd output broken.

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

Jan 16 2017, 8:52 AM · rc, Bug Report, gnupg, TOFU

Jan 14 2017

neal added a comment to T2914: TOFU Conflict Status fd output broken.

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?

Jan 14 2017, 11:31 PM · rc, Bug Report, gnupg, TOFU

Jan 6 2017

werner added a project to T2914: TOFU Conflict Status fd output broken: rc.
Jan 6 2017, 7:06 PM · rc, Bug Report, gnupg, TOFU