@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.
Is anyone working on this? Just want to confirm.
Sun, Dec 8
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?
Sat, Dec 7
Fri, Dec 6
Thu, Dec 5
Tue, Nov 26
Mon, Nov 25
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.
Thu, Nov 21
Mon, Nov 18
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:
Thu, Nov 14
Nov 8 2019
El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <email@example.com>
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.
Nov 7 2019
Oct 31 2019
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.
Oct 30 2019
Oct 24 2019
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.
Oct 19 2019
On July, 19th, @werner wrote:
You need to wait a bit more.
Oct 15 2019
Oct 14 2019
@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?
Oct 9 2019
Oct 7 2019
Sep 27 2019
Sep 15 2019
The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.
Sep 12 2019
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.