Apr 10 2020
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.
Mar 12 2020
Feb 6 2020
Install the zlib development package, its name is often "zlib1g-dev". The source requires the header because we plan to eventually support compression.
Jul 10 2019
I pushed my change as: rT7b2c4d9dd50b: Support GCM.
Jul 3 2019
Jul 2 2019
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.
Jul 1 2019
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.
Jun 8 2019
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!
Feb 19 2019
Jan 17 2019
It is fixed in master branch of the repo.
Jan 10 2019
Dec 30 2018
Dec 17 2018
Dec 13 2018
Oct 29 2018
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.
Oct 26 2018
Oct 25 2018
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.
Oct 24 2018
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:
Oct 16 2018
Oct 10 2018
Done for gpgme.