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: <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 writes: > Simon Josefsson writes: > >> Daiki Ueno 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: <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 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 writes: > >> Simon Josefsson writes: >> >>> Daiki Ueno 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: