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
Fri, Nov 8
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.
Thu, Nov 7
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.
Sep 9 2019
As far as I know this works.
This works but might have created a regression which is tracked in T4701
I give this normal priority even if it is a whish because I have the same whish and already have some code around that would make it more comfortable, especially if it is used directly in GpgOL.
I still would like to test this some more and work on it. I think the implemnation might still be a bit fragile.
Sep 8 2019
Here is an example containing such a Attestation Signature:
Sep 6 2019
BTW: I have the problem that I want to know the keys of all cards. "getinfo card_list" along with --demand can be used for this. gpg-card works this way. It does not work if plug in addtional cards becuase card_list shows only the cards for which a SERIALNO command has been used. A new feature to scan the buses for all readers and cards would be quite useful.