On 06/01/2018 04:36 PM, Daniel Gustafsson wrote:
>> On 1 Jun 2018, at 05:05, Daniel Stenberg <daniel_at_haxx.se> 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
Received on 2018-06-02