Buy commercial curl support from
WolfSSL. We help you work out your issues, debug your libcurl
applications, use the API, port to new platforms, add new features and more.
With a team lead by the curl founder himself.
Re: When will we make TLS 1.3 support a mandatory requirement?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 8 Mar 2024 10:56:13 +0100 (CET)
On Fri, 8 Mar 2024, Dave Cottlehuber wrote:
> Personally I agree with your position, but I can't help imagine a lot of
> small software projects having conniptions if they've spent 5 years using
> library X only to find out that it's not supported in the future.
I don't think that would be our fault. We have already dropped support for
multiple TLS libraries in the past simply because they have fallen below the
threshold of what is okay. That's certainly most unfortunate, but curl
supports lots of alternatives (while exposing the same stable API) so given
some time, most users can switch over to a suriving option.
Evolution and development is a thing. Over time and over the years, products
come and go. No one is ever safe from the risk that whatever shoulder you
decide to stand upon, it may vanish one day. And we all stand on shoulders.
> Perhaps its worth asking those library authors directly how they're handling
> keeping up with modern TLS, and also what their position might be if the
> Worlds Most Popular Library(tm) rug-pulled their support?
I think rug-pull is an overly drastic term for a situation that A) is warned
about waaaaay in advance, B) we offer plenty of alternative rugs to replace
the old rugged one with and, C) the rug-makers themselves can get even their
act together and fix them.
The mere potential threat of taking this route might push option C to happen,
which then will benefit lots of users. In fact, I have already recevied word
from people working on mbedTLS that they will work on making sure they are not
culled. Something no one had said two days ago.
> I expect their most plausible commercial step would be *not* to upgrade
> libcurl, better to preserve compatibility, which would overall not be a win
> for security and reliability of libcurl and friends.
The curl project needs to take many different factors, users and use cases
into account when making decisions. I believe strongly in slowly and gently
tightening the bolts and the screws in the curl ship as we move forward. To
gradually raise the requirements on third party libs, to slowly and over the
years trim off the laggards that don't follow the evolution enough. And of
course to also improve our own code and standards for doing things. For the
greater good of all users and the world really.
This is what flying with curl means to me. Safe, secure, fast and rock solid
Internet transfers. In every Internet connected device on the globe.
This is not an already made decision. This is a conversation because of all
these reasons.
Date: Fri, 8 Mar 2024 10:56:13 +0100 (CET)
On Fri, 8 Mar 2024, Dave Cottlehuber wrote:
> Personally I agree with your position, but I can't help imagine a lot of
> small software projects having conniptions if they've spent 5 years using
> library X only to find out that it's not supported in the future.
I don't think that would be our fault. We have already dropped support for
multiple TLS libraries in the past simply because they have fallen below the
threshold of what is okay. That's certainly most unfortunate, but curl
supports lots of alternatives (while exposing the same stable API) so given
some time, most users can switch over to a suriving option.
Evolution and development is a thing. Over time and over the years, products
come and go. No one is ever safe from the risk that whatever shoulder you
decide to stand upon, it may vanish one day. And we all stand on shoulders.
> Perhaps its worth asking those library authors directly how they're handling
> keeping up with modern TLS, and also what their position might be if the
> Worlds Most Popular Library(tm) rug-pulled their support?
I think rug-pull is an overly drastic term for a situation that A) is warned
about waaaaay in advance, B) we offer plenty of alternative rugs to replace
the old rugged one with and, C) the rug-makers themselves can get even their
act together and fix them.
The mere potential threat of taking this route might push option C to happen,
which then will benefit lots of users. In fact, I have already recevied word
from people working on mbedTLS that they will work on making sure they are not
culled. Something no one had said two days ago.
> I expect their most plausible commercial step would be *not* to upgrade
> libcurl, better to preserve compatibility, which would overall not be a win
> for security and reliability of libcurl and friends.
The curl project needs to take many different factors, users and use cases
into account when making decisions. I believe strongly in slowly and gently
tightening the bolts and the screws in the curl ship as we move forward. To
gradually raise the requirements on third party libs, to slowly and over the
years trim off the laggards that don't follow the evolution enough. And of
course to also improve our own code and standards for doing things. For the
greater good of all users and the world really.
This is what flying with curl means to me. Safe, secure, fast and rock solid
Internet transfers. In every Internet connected device on the globe.
This is not an already made decision. This is a conversation because of all
these reasons.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-03-08