Fixed in rC0ff36e04f7cd: ecc: Remove hard-coded value for ECC_DIALECT_ED25519..

There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).

Could you guide me to where I find the beta or snapshot, so I could test it and give you feedback? I seem to be unable to find it on my own.

Push the change to master.

That's odd. :-)

FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :

Thanks for your report. The problem of GnuPG was that it mandated padding length < 16 bytes, which is wrong.

Pushed the changes.

It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

This should work well with libksba master and gnupg/sm master.

The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).

Backported to 2.2

I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

Fixed in master.

I pushed the change to master.

I can confirm that the problem is gone from a build from the master branch. It indeed retries the search.

Implemented in master.

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info

In 2.2.18, this fix is not included. (partial fix was reverted)

This will be in 2.2.18, closing.

Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.

Please test. When I can confirm that it is stable, I'll backport it to 2.2.

Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

I also think this makes the most sense.

In my opinion, --locate-key should locate encryption key.

@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC

There are some problems with the definition of --locate-key. Further discussion required.

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

gpg4win 3.1.6 is released which contains this fix.

Changes backported to 2.2

We also need to fix for encryption and signature in CSR.

Builds fine now with GCC 9. Thanks for looking into this so quickly.

Fixed in master, by removing use of compound literals. Compound literals are not portable feature (even for C99 code), so, it's good to avoid when we can.
Still dns.c uses C99 features of struct initializer with name.

Fixed in master.

No more complaints thus time to close.