Thu, Jun 16
Tue, Jun 14
ntbtls support only 1.2. We can't disable cipher suites for interop reasons. It is not the client's job trying to force a server 's admin to offer only decent ciphersuites.
Mon, Jun 13
May 23 2022
ntbltls does not implement compression:
Apr 14 2022
We have not seen this problem anymore in recent versions. Thus closing.
Feb 28 2022
In TLS 1.2, it refers RFC5116. In RFC5116, it says:
My reading was wrong; Indeed we use memcpy from out_ctr. But it increments in network byte order.
So, for AES-GCM, it works well.
Nov 23 2021
Might be a TOR Thing?
Nov 10 2021
Also applied to gpgme.
Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.
Nov 3 2021
Sep 27 2021
These are great news. Thank you!
Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.
Thank you for the information.
For the record, I put the link to the email submitted:
Sep 22 2021
Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:
I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?
Sep 21 2021
That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:
That does indeed not look like something which could introduce a regression.
I misunderstood as if we need to update libtool from upstream.
macOS has low priority for us and I do not want to risk any regression.
About merging our local changes.
We have our own changes for ltmain.sh and libtool.m4.
And update from automake 1.16:
It's better to update the set of files from libtool:
build-aux/ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4
Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
Aug 13 2021
Mar 29 2021
Please look at the code:
Mar 28 2021
Jan 11 2021
Aug 28 2020
I think we should make zlib a mandatory dependency.
Actually, configure already has the check.
If it's really needed to build without zlib, you can use this patch:
From 76920ac034490e4860ad6abe9891e3b1c0813363 Mon Sep 17 00:00:00 2001 From: NIIBE Yutaka <email@example.com> Date: Fri, 28 Aug 2020 11:02:13 +0900 Subject: [PATCH] Until compression is implemented, build with no ZLIB can be done.
Aug 27 2020
0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me
Jun 3 2020
Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.
Jun 1 2020
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.