Has been released with 2.3.0 and we better open a new task if problems show up with v5 key. I am pretty sure that there will be a few v5 key problems after they get in real use.

Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.

Done in 2.3.0.

Done in 2.3.0.

Done in 2.3.

Sorry to dig up an old report...

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

Ah, I see that when there is no card reader, it returns "Service is not running" with PC/SC.
Let's fix that.

When testing under Windows "scd devinfo --watch" returns immediately with ERR 100663614 Service is not running <SCD>
Probably also if you would use PC/SC on Linux but I have not tested this.

More than a year in testing, and I have not seen problems myself anymore.

Works for me.

Thanks for the fix.

pubkey_cmp should be symmetric (pubkey_cmp(A,B) == - pubkey_cmp(B,A)), but it was not.

The problem persists when using keyboxd which returns keys in a different order.

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/posix_spawn.2.html dated August 9, 2007.
So, I guess that posix_spawn became available in MacOS X Leopard (10.5).

Also support older MacOS X, which has no posix_spawn.

T4702 is our release info task for 2.3.0

@gniibe Hi! Can you estimate, when this feature will be released?
I have not found this patch in the latest GnuPG release tags (in the Git repository) either by the name or the commit hash.

Do you mean self-signed certs or what kind of certs do not work?

@gniibe I assume this issue has been fixed by the same fix as for T4585 and can be closed as well. Feel free to re-open if I am wrong.

Docs done.

For a bug which requires more tests (like this one with GnuPG and pinentry), I had a practice to put "Testing" tag.

Any news about this bug? It has been in “Testing” for quite a while now. For what it’s worth, handling of ^C seems to work here as I would expect, so I am inclined to close here and let pinentry-1.1.1 go out. @gniibe, as you did the fix, do you have any comment?

gcry_ecc_get_algo_keylen has been added with commit a658c9ccc2c741f40b0b5cdbcd184cfb9a841d17 but documentation is missing.

I think we can close this one, right?

Hi there, this change is very useful on the Homebrew project's upcoming ARM port. The Mac package manager's base library prefix will change from the existing presumed defaults to prevent backwards-incompatibility, making pkg-config compatibility somewhat more important.

In T2291#140172, @gniibe wrote:

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey.. This was introduced by the support of PIV feature of Yubikey.

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey., which is fixed already. This was introduced by the support of PIV feature of Yubikey.

Report on some testing using master:

This works now. Thanks.

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

I think that T5150 was also not fixed completely.

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

Works now. Thanks.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

Great. Please apply the patch.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Stable now and works as expected. Thank you!

Its done for 2.2 thus changing the tag.