In T2905#97835, @wltjr wrote:

I am not sure where the underscore comes from. Seems to come from pinentry, but GTK and QT do not have that, so I think its something I am doing wrong.

And 5 euros quarterly to 60 euros yearly, etc.

There is a prototype implementation in the branch neal/encrypted-mailing-lists . A paper describing the design is at: ftp://ftp.gnupg.org/people/neal/openpgp-mailing-lists.pdf . The design was reviewed by Matt Green and DKG. DKG suggested using a slightly different OpenPGP construct (specfically, using user attribute packets instead of my encrypted subkey hack).

I marking this as resolved since I think the issue is fixed. If this is not the
case, please reopen.

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

This should be fixed in b1106b4 . The problem had to do with an incorrect
assumption that a key with policy 'ask' necessarily had at least one conflict.
This assumption may not hold if --tofu-default-policy is set to ask.
Thankfully, the assertion caught this.

Thanks for reporting this. I can reproduce it and will hopefully have a good
fix soon.

Glenn: I'm not exactly sure why your scenario exposed this issue. I suspect
that it has something to do with you have never used this key for encryption
prior to the verification, but it would require more investigation to confirm.

Unfortunately, it is also used in the test suite to deal with expiration times.

This should be fixed by 407f5f9baea5591f148974240a87dfb43e5efef3 .

Thanks for reporting this!

According to SUSv3:

If the subject sequence is empty or does not have the expected form, no

conversion is performed

...
If no conversion could be performed, 0 is returned  and errno may be set to

[EINVAL].

  http://pubs.opengroup.org/onlinepubs/007908799/xsh/strtol.html

It appears that MacOS X sets errno to EINVAL, but glibc doesn't.
(The attached program should expose the behavior; I haven't run it yet on Max OS
X, but I'd be interested in the result.)

The underlying problem is that bindings for ultimately trusted keys were not
registered with the TOFU data.

Fixed in 769272ba87f282a69e8d5f9bb27c86e6bec4496b

This should be fixed in 027b81b35fe36692005b8dba22d9eb2db05e8c80.

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.

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?

Also see: https://github.com/mabels/gnupg/tree/quick-keytocard

FWIW, I doubt that 2.1.17 fixes the issue. But, I've improved the debugging
out, so if you would try to reproduce the problem, it would still be useful.
Thanks!

Thanks for the feedback! Can you please compile gpg with debugging symbols, add
a break point on log_debug in string_to_ulong (in g10/tofu.c), and then do 'run
--verify ts.txt'. When you hit the breakpoint, please do a 'bt full', print out
the value of "string" and "tail" (using gdb's 'p' command), and repeat (continue
execution using 'c').

Thanks!

Thanks! I tried reproducing this issue with your tofu.db (using HEAD), but I
didn't see the warning:

$ gpg --verify /tmp/TrueTimeStamp-certificate-4793.txt
gpg: Signature made Thu 24 Nov 2016 08:08:29 AM CET
gpg: using DSA key 6F3B2E6AB748A8F8
gpg: Good signature from "TrueTimeStamp <signing-department@TrueTimeStamp.org>"
[marginal]
gpg: signing-department@truetimestamp.org: Verified 2 signatures in the past

12 days.  Encrypted 0 messages.

gpg: Warning: you have yet to encrypt a message to this key!
gpg: Warning: if you think you've seen more signatures by this key and user

id, then this key might be a forgery!  Carefully examine the email address
for small variations.  If the key is suspect, then use
  gpg --tofu-policy bad 83289060F40DED088CF246B56F3B2E6AB748A8F8
to mark it as being bad.

gpg: WARNING: This key is not certified with sufficiently trusted signatures!
gpg: It is not certain that the signature belongs to the owner.
Primary key fingerprint: 8328 9060 F40D ED08 8CF2 46B5 6F3B 2E6A B748 A8F8

Most likely, this is because when you verifies the message, the error was fixed.
Can you confirm this for me by trying to reproduce the error with your current
tofu.db? If there is no error, could you send me a copy of the tofu.db from
before the initial verification?

Thanks!

In general, parallel operations aren't great, but I find that such bad
performance surprising.

If you update a key, only that key's effective policy is rechecked, not all
keys. But, the effective policy of conflicting keys is always rechecked.

No need to apologize for the dup; I was just noting it here for the record.

I think that your assumption is that the local keyring is somehow trusted. In
that case, I think it make sense that deleted keys would clear conflicts.

I'm curious when you think people delete keys. My intuition is that it is not a
very common pattern. Do you have any thoughts on this?

I encourage you to first try and find a consensus before implementing a
different policy at the higher level.

Thanks for reporting this! Unfortunately, I'm not able to reproduce this. I
hope you can help me figure out what is wrong. Would you be willing to share
your tofu.db with me? Feel free to send it to me directly
(8F17777118A33DDA9BA48E62AACB3243630052D9); it contains some privacy sensitive
information (namely, who you communicate with).

Thanks!

This issue has also been reported in https://bugs.gnupg.org/gnupg/Issue2859

Werner replied there and I agree with his conclusion.

Note: this is a dup of T2742

I tend to agree with Werner: if we discover a conflict, it needs to be resolved
and deleting a key is not a sufficient resolution.

This should be fixed in: 2f27cb12e30c9f6e780354eecc3ff0039ed52c63 .