Hi, Please review the change and feedback.

Verified in ntbtls-0.3.2.

Fixed in 0.3.2.

Fixed in NtbTLS 0.3.2.

Noteworthy changes in version 0.3.2 (2024-01-12)

Yeah we should do an ntbtls release. As a core library it does no matter much which workboard we use. Let's remove it the vsd tag.

So the last thing to do here would be an NTBTLS release? Then we should make sure not to forget to do that?

Well, even out new versions.gnupg.org uses a shorter hash. Better get that released asap.

I can't see what we shall do here.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

Pushed the change.

There is a description: https://datatracker.ietf.org/doc/html/rfc8422#section-5.10

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.

ntbltls does not implement compression:

We have not seen this problem anymore in recent versions. Thus closing.

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.

Might be a TOR Thing?

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.

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:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

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: