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:

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?

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.