Thanks for testing. It's actually an error of generating _unicode_mapping.c, which utf8.c includes.

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

In the function nist_generate_key (cipher/ecc.c), ec->nbits is number of bits of P.
... while mpi/ec.c sets 256.

It's a kind of "bug compatibility" but it's a regression anyway.

I can't find any places where it is interpreted as signed integer.

It was a problem of libgcrypt master.
As of today's libgcrypt rC60c179b59e53: sexp: Extend gcry_sexp_extract_param with new format specifiers., it works fine.

It seems it's a falure of ECDH.
I ran a server by s_server and saw following error:

$ openssl s_server -key key.pem -cert cert.pem -accept 44330 -www
Using default temp DH parameters
ACCEPT
140203176436992:error:10067064:elliptic curve routines:ec_GFp_simple_oct2point:buffer too small:../crypto/ec/ecp_oct.c:280:
140203176436992:error:1419C010:SSL routines:tls_process_cke_ecdhe:EC lib:../ssl/statem/statem_srvr.c:3245:

Because it also fails in 0.1.2 (with no GCM support), it seems that it's not GCM thing.

Push the change to master.

It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.

Your example data is malformed, I suppose.

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

I'm testing this as an initial start:

ac_ext=c
ac_objext=o

@jukivili : Thank you. Please apply & push it.

Pushed the changes.

OK. I reopen this ticket to collect information.

I think that it is compiler issue for AltiVec (now, VSX) support.
The usage is not ambiguous. It _is_ ambiguous in the header file.

Thansk for your report.

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.

The problem itself is fixed (in T4495: UBsan finding "certdump.c:695:3: runtime error: null pointer passed as argument 2"). The variable buffer cannot be NULL at memcpy.

genkey for Ed25519 works now with libksba in master.

For public key, it's done.

NIST P-256 key generation looks good.

There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

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).

For operations which require private key, it is needed to unlock private key.

You forwarded me an email, which said it went well.

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/