Re: 4.0 planning (Re: nettle 4.0 compatibility

--===============4882617150763219515==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain

Daiki Ueno <[email protected]> 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 <[email protected]> writes:
>
>> Simon Josefsson <[email protected]> writes:
>>
>>> Daiki Ueno <[email protected]> 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,

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmAlQoUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFovyzAP9Ez2bOtgu4
mJE9GbCcMjnxxMxcxqH92cTSTUdSfCWiVwEA5f7NMZfWTK3Nz+DzsW3CGH3mPAO6
1UIoDRIQ0ShCbgw=
=sTJY
-----END PGP SIGNATURE-----
--=-=-=--


--===============4882617150763219515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help

--===============4882617150763219515==--