@werner, i don't understand your last remark. what "required computations" do you think the proposed patches are "moving" from the server to the client?

Oh, no worries! Just wanted to confirm, that's all.

I am about half way. Sorry for the slowness.

I've been wondering this also. I can start working on this.

Hello,
Is anyone working on this? Just want to confirm.

I see no reason to move required computations from the server to the client.

@werner Could you please give an update on this? Is there any blocker? Is something missing, which prevents merging (and releasing) this?

In T1287#94619, @werner wrote:

2.1 has the option --unwrap to just this.

Unusable v6 interfaces are now detected on Windows and then not used.

To be clear, i believe @mgorny means that he wants the User ID containing the e-mail address to be considered *valid* (that is, full or ultimate validity). I don't think this operation should care about ownertrust.

it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:

El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:

Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

C-based intrinsic implementations are discouraged.

No. I mean to have an option for the caller to provide apparent UID in context to the --verify option, and have that influence the result. This is important for automated software that can't rely on user rechecking the result.

So you mean we should take the signer's UID (which can be part of the signature) into account when displaying the user id? Right now we display the primary UID followed by _all_ other user IDs so that the verifier has an overview of the associated user ids.

There is a growing bit of popular lore in the GnuPG community that "when keyserver operations fail, you solve that problem with killall dirmngr." I believe this suggestion is potentially damaging (the long-running daemon may be in the middle of operations for a client that you don't know about), but i suspect it is circulating as advice because it resolves the situation outlined in this ticket. For whatever ephemeral reason, dirmngr gets stuck, and fails to notice that this situation has resolved itself.

On July, 19th, @werner wrote:

You need to wait a bit more.

@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?

In T4475#124816, @werner wrote:

Put

log-file /somewhere/scd.log
debug ipc,cardio
verbose

into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a

debug-ccid-driver

in scdaemon.conf will also be helpful.

The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.

In T2300#90092, @aheinecke wrote:

Ah nevermind. I think myself that this is nobug and current behavior is correct.

To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.