From ametzler at bebt.de  Tue Jan 27 18:33:13 2026
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 27 Jan 2026 18:33:13 +0100
Subject: [gnutls-help] nettle 4.0 compatibility
Message-ID: <aXj22fZ-0XP3MHWC@argenau.bebt.de>

Hello,

Nettle-4.0rc1 has been announced recently. It has dropped some legacy
code that is still used by gnutls, e.g. multiple files in
/lib/accelerated have #include <nettle/sha.h> or use SHA1_DATA_SIZE.

Is this already being worked somewhere I did not find or should I open ticket
in the issue-tracker?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ueno at gnu.org  Thu Jan 29 09:47:57 2026
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 29 Jan 2026 17:47:57 +0900
Subject: [gnutls-help] nettle 4.0 compatibility
In-Reply-To: <aXj22fZ-0XP3MHWC@argenau.bebt.de> (Andreas Metzler's message of
 "Tue, 27 Jan 2026 18:33:13 +0100")
References: <aXj22fZ-0XP3MHWC@argenau.bebt.de>
Message-ID: <878qdghkjm.fsf-ueno@gnu.org>

Hello,

Andreas Metzler <ametzler at bebt.de> writes:

> Nettle-4.0rc1 has been announced recently. It has dropped some legacy
> code that is still used by gnutls, e.g. multiple files in
> /lib/accelerated have #include <nettle/sha.h> or use SHA1_DATA_SIZE.
>
> Is this already being worked somewhere I did not find or should I open ticket
> in the issue-tracker?

Thank you for the reminder.  I just opened an issue:
https://gitlab.com/gnutls/gnutls/-/issues/1791

On a slightly related note, we might also want to plan a new major
release (3.9 or 4.0) with backward incompatible changes, such as default
cipher selections. If we were to have a call to discuss that, would
there be anyone interested to join? I'll create a wiki page to list
those by then anyway.

Regards,
-- 
Daiki Ueno


From simon at josefsson.org  Thu Jan 29 22:46:27 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Jan 2026 22:46:27 +0100
Subject: [gnutls-help] nettle 4.0 compatibility
In-Reply-To: <878qdghkjm.fsf-ueno@gnu.org> (Daiki Ueno's message of "Thu, 29
 Jan 2026 17:47:57 +0900")
References: <aXj22fZ-0XP3MHWC@argenau.bebt.de> <878qdghkjm.fsf-ueno@gnu.org>
Message-ID: <87sebo1498.fsf@josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

> On a slightly related note, we might also want to plan a new major
> release (3.9 or 4.0) with backward incompatible changes, such as default
> cipher selections.

What kind of backward incompatible API/ABI change are you thinking of?

I think doing backwards incompatible changes that affect running code
out there is often just a bad idea, so IMHO it would be nice to
enumerate the API/ABI changes for consideration, and then run reverse
builds of Debian/Fedora packages using GnuTLS to see what breaks.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20260129/81cdf18f/attachment.sig>

From ueno at gnu.org  Thu Jan 29 23:32:46 2026
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 30 Jan 2026 07:32:46 +0900
Subject: [gnutls-help] nettle 4.0 compatibility
In-Reply-To: <87sebo1498.fsf@josefsson.org> (Simon Josefsson's message of
 "Thu, 29 Jan 2026 22:46:27 +0100")
References: <aXj22fZ-0XP3MHWC@argenau.bebt.de> <878qdghkjm.fsf-ueno@gnu.org>
 <87sebo1498.fsf@josefsson.org>
Message-ID: <87y0lg1241.fsf-ueno@gnu.org>

Simon Josefsson <simon at josefsson.org> writes:

> Daiki Ueno <ueno at gnu.org> writes:
>
>> On a slightly related note, we might also want to plan a new major
>> release (3.9 or 4.0) with backward incompatible changes, such as default
>> cipher selections.
>
> What kind of backward incompatible API/ABI change are you thinking of?

I meant more about backward incompatible "behavior" changes, such as:
https://gitlab.com/gnutls/gnutls/-/issues/1761
https://gitlab.com/gnutls/gnutls/-/issues/1772

> I think doing backwards incompatible changes that affect running code
> out there is often just a bad idea, so IMHO it would be nice to
> enumerate the API/ABI changes for consideration, and then run reverse
> builds of Debian/Fedora packages using GnuTLS to see what breaks.

I agree.  Even if we disable some already deprecated functionality, such
as SRP, we will likely keep the API/ABI (but may turn it no-op).

Regards,
-- 
Daiki Ueno