On 06/01/2018 04:36 PM, Daniel Gustafsson wrote:
On 1 Jun 2018, at 05:05, Daniel Stenberg <[email protected]> wrote:
- doesn't support modern TLS features like SNI? [1]
- lacks support for modern ciphers [5]
I think this brings up an important point. Should curl have a baseline set of
features that are mandatory for a TLS library to be supported?
This can apply when you really have alternatives: are there platforms
where only axTLS is available? Has axTLS some feature that no other
backend has ? Maybe a small footprint for embedded designs, or something
similar ? I'm afraid I call it a feature even if it is not directly
related to TLS itself or the project management.
Taking the OS400 case in example: there are only 2 TLS libraries
available on this platform: QSOSSL and GSKit. Neither of them support
modern features like TLS 1.3 or OCSP stappling or shared sessions, even
in the latest version of the OS; they are proprietary closed source
libraries; there's no "bugzilla" for them, etc. Historically, a curl
QSOSSL has been implemented first, then a GSKit one that was far better
than the first. As you can see, the QSOSSL backend has been dropped
since then, but I wont remove the GSKit one for lack of some "mandatory"
features reasons, because there are no alternative on this OS.
Of course, I'm talking about live projects: deprecated or poorly
maintained ones would surely become rapidly insecure and should probably
not be featured by libcurl anymore.
IMHO this should be examined on a case by case basis like Daniel does
for axTLS, and not be limited by a "checklist".
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
