From ueno at gnu.org  Mon Feb  2 10:31:16 2026
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 02 Feb 2026 18:31:16 +0900
Subject: [gnutls-help] 4.0 planning (Re: nettle 4.0 compatibility
In-Reply-To: <87y0lg1241.fsf-ueno@gnu.org> (Daiki Ueno's message of "Fri, 30
 Jan 2026 07:32:46 +0900")
References: <aXj22fZ-0XP3MHWC@argenau.bebt.de> <878qdghkjm.fsf-ueno@gnu.org>
 <87sebo1498.fsf@josefsson.org> <87y0lg1241.fsf-ueno@gnu.org>
Message-ID: <87ecn3jxuj.fsf_-_-ueno@gnu.org>

Hello,

I've created a wiki page to collect significant changes planned for
GnuTLS 4.0 (or 3.9):
https://gitlab.com/gnutls/gnutls/-/wikis/Planning-for-4.0

If you have any further ideas or disagree with the currently planned
items, don't hesitate to speak up :-)

Regards,

Daiki Ueno <ueno at gnu.org> writes:

> 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,


From simon at josefsson.org  Mon Feb  2 13:14:02 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 02 Feb 2026 13:14:02 +0100
Subject: [gnutls-help] 4.0 planning (Re: nettle 4.0 compatibility
In-Reply-To: <87ecn3jxuj.fsf_-_-ueno@gnu.org> (Daiki Ueno's message of "Mon,
 02 Feb 2026 18:31:16 +0900")
References: <aXj22fZ-0XP3MHWC@argenau.bebt.de> <878qdghkjm.fsf-ueno@gnu.org>
 <87sebo1498.fsf@josefsson.org> <87y0lg1241.fsf-ueno@gnu.org>
 <87ecn3jxuj.fsf_-_-ueno@gnu.org>
Message-ID: <87wm0vs5px.fsf@josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

> Hello,
>
> I've created a wiki page to collect significant changes planned for
> GnuTLS 4.0 (or 3.9):
> https://gitlab.com/gnutls/gnutls/-/wikis/Planning-for-4.0

+1 to dropping srptool, but keeping gnutls_srp* for ABI but returning
failure.

I think libgnutls-openssl never really took off.  Is anyone using this?
I wonder about its usefulness.

I worry a bit about hard-depending on Nettle 4.0 if this makes building
on some still supported platforms (RHEL9?) problematic.  Couldn't we
depend on Nettle 4.x for ML-KEM/DSA and if Nettle 4.x is not available,
simply not support ML-KEM/DSA?  OTOH if this means regressing from
having supported ML-KEM/DSA via leancrypto, maybe this is not a good idea.

/Simon

> If you have any further ideas or disagree with the currently planned
> items, don't hesitate to speak up :-)
>
> Regards,
>
> Daiki Ueno <ueno at gnu.org> writes:
>
>> 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,
-------------- 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/20260202/e1722680/attachment.sig>

From asosedkin at redhat.com  Mon Feb  9 17:25:10 2026
From: asosedkin at redhat.com (Alexander Sosedkin)
Date: Mon, 9 Feb 2026 10:25:10 -0600
Subject: [gnutls-help] gnutls 3.8.12
Message-ID: <CABMV8QNfycuBvhrHyKqP1D6XYe38v2DH_5iK-dvsa2Zav=Lp+Q@mail.gmail.com>

Hello,

We have just released gnutls-3.8.12. This is a bug fix, security and
enhancement release on the 3.8.x branch.

We would like to thank everyone who contributed in this release:
Alexander Sosedkin, Daiki Ueno, Mikhail Dmitrichenko, Franti?ek Kren?elok,
Jan Palus, Julien Olivain, Markus Theil, Maxim Cournoyer, xinpeng wang.

The detailed list of changes follows:

* Version 3.8.12 (released 2026-02-09)

** libgnutls: Fix NULL pointer dereference in PSK binder verification
   A TLS 1.3 resumption attempt with an invalid PSK binder value in ClientHello
   could lead to a denial of service attack via crashing the server.
   The updated code guards against the problematic dereference.
   Reported by Jaehun Lee.
   [Fixes: GNUTLS-SA-2026-02-09-1, CVSS: high] [CVE-2026-1584]

** libgnutls: Fix name constraint processing performance issue
   Verifying certificates with pathological amounts of name constraints
   could lead to a denial of service attack via resource exhaustion.
   Reworked processing algorithms exhibit better performance characteristics.
   Reported by Tim Scheckenbach.
   [Fixes: GNUTLS-SA-2026-02-09-2, CVSS: medium] [CVE-2025-14831]

** libgnutls: Fix multiple unexploitable overflows
   Reported by Tim R?hsen (#1783, #1786).

** libgnutls: Fall back to thread-unsafe module initialization
   Improve fallback handling for PKCS#11 modules that
   don't support thread-safe initialization (#1774).
   Also return filename from p11_kit_module_get_name() for unconfigured modules.

** libgnutls: Accept NULL as digest argument for gnutls_hash_output
   The accelerated implementation of gnutls_hash_output() now
   properly accepts NULL as the digest argument, matching the
   behavior of the reference implementation (#1769).

** srptool: Avoid a stack buffer overflow when processing large SRP groups.
   Reported and fixed by Mikhail Dmitrichenko (#1777).

** API and ABI modifications:
No changes since last version.


Getting the Software
================

GnuTLS may be downloaded directly from
https://www.gnupg.org/ftp/gcrypt/
A list of GnuTLS mirrors can be found at
http://www.gnutls.org/download.html

Here are the XZ compressed sources:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.12.tar.xz

Here are OpenPGP detached signatures signed using keys:
5D46CB0F763405A7053556F47A75A648B3F9220C
and
E987AB7F7E89667776D05B3BB0E9DD20B29F1432
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.12.tar.xz.sig

Note that it has been signed with the following openpgp keys:

pub   ed25519 2021-12-23 [SC] [expires: 2027-01-01]
      5D46CB0F763405A7053556F47A75A648B3F9220C
uid           [ultimate] Zoltan Fridrich <zfridric at redhat.com>
sub   cv25519 2021-12-23 [E] [expires: 2027-01-01]

pub   rsa4096 2016-09-27 [SC]
      E987AB7F7E89667776D05B3BB0E9DD20B29F1432
uid           [ultimate] Alexander Sosedkin <monk at unboiled.info>
sub   rsa4096 2021-08-21 [A]
sub   rsa4096 2016-09-27 [E]
sub   rsa4096 2016-09-27 [S]


Regards,
Alexander Sosedkin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20260209/2181c01c/attachment.sig>

From antonio at gnu.org  Wed Feb 11 16:57:05 2026
From: antonio at gnu.org (Antonio Diaz Diaz)
Date: Wed, 11 Feb 2026 16:57:05 +0100
Subject: [gnutls-help] gnutls 3.8.12
In-Reply-To: <CABMV8QNfycuBvhrHyKqP1D6XYe38v2DH_5iK-dvsa2Zav=Lp+Q@mail.gmail.com>
References: <CABMV8QNfycuBvhrHyKqP1D6XYe38v2DH_5iK-dvsa2Zav=Lp+Q@mail.gmail.com>
Message-ID: <698CA6D1.5090503@gnu.org>

Alexander Sosedkin wrote:
> We have just released gnutls-3.8.12.

Congratulations on the new release. :-)

> Here are the XZ compressed sources:

Have you considered using any other compressed format? I find it somewhat 
odd that a secure communications library is distributed using about the only 
format that does not guarantee the integrity of the decompressed data 
against decompression errors. See, for example, 
http://www.nongnu.org/lzip/xz_inadequate.html#checking . Note that a 
cryptographic signature of the compressed file does not protect against 
decompression errors caused by faulty RAM or bugs in the decompressor.

Gzip, bzip2, and lzip always check the integrity of the decompressed data, 
and therefore would be fine. Zstd may also be adequate in practice because, 
even if its integrity checking is optional, I don't know of any zstd 
decompressor that does not implement it.

Thanks,
Antonio.


From simon at josefsson.org  Wed Feb 11 22:11:06 2026
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Feb 2026 22:11:06 +0100
Subject: [gnutls-help] gnutls 3.8.12
In-Reply-To: <698CA6D1.5090503@gnu.org> (Antonio Diaz Diaz's message of "Wed, 
 11 Feb 2026 16:57:05 +0100")
References: <CABMV8QNfycuBvhrHyKqP1D6XYe38v2DH_5iK-dvsa2Zav=Lp+Q@mail.gmail.com>
 <698CA6D1.5090503@gnu.org>
Message-ID: <87seb70yvp.fsf@josefsson.org>

Antonio Diaz Diaz <antonio at gnu.org> writes:

>> Here are the XZ compressed sources:
>
> Have you considered using any other compressed format?

I think file size isn't as important as it used to be, and today it is
more important to think about other matters including
bootstrap/reproducible-build and supply-chain concerns.

I find the arguments to chose anything beyond gzip are rather weak
today.  I changed GNU InetUtils to gzip recently (from xz+gz).

Sometimes I have considered publishing non-compressed tarballs to not
have to deal with compression concerns, but I suspect that may be less
portable than compressed tarballs.  And I don't see any realistic
computing platform lacking gzip anyway.

Changing compression algorithm has a cost too.  I'm not convinced the
arguments for any particular compression method are strong enough to
warrant switching.

XZ is really slow compared to zstd which is what I would use in any
performance-critical situation.

This is a great bike shed :)

/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/20260211/c40ab32a/attachment.sig>