I think I fixed a memory leak on error but no other changes for old code except that the array to old the args now takes void* and not gcry_mpi_t - which does not make a difference.

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.

Install the zlib development package, its name is often "zlib1g-dev". The source requires the header because we plan to eventually support compression.

I pushed my change as: rT7b2c4d9dd50b: Support GCM.
Please test.

In T4597#127637, @Valodim wrote:

Done. Hopefully this works now :)

https://www.ssllabs.com/ssltest/analyze.html?d=keys.openpgp.org

Done. Hopefully this works now :)

Anything using CBC mode - ECC is just fine.

Which is a bad idea because CBC is still a very common cipher mode.

They can't agree on a common ciphersuite. The reason is that the server does not support any CBC mode. Which is a bad idea because CBC is still a very common cipher mode.

If I understand correctly, this is exactly the same problem that the one we encountered some time ago in the code dealing with fetching keys from HTTP (--fetch-keys), and that we fixed with this patch.

fwiw, the bug looks like it's in send_request in ks-engine-hkp.c, which re-uses the http_session object without re-initializing its tls_session member.

thanks for the triage, @werner!

It is fixed in master branch of the repo.

Applied.

New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.

It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.

Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.

OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

This is the dependency graph:

Done for gpgme.

Done for npth.