On Fri, 1 Jun 2018, Daniel Gustafsson wrote:

> 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?

That's a very good question!

Traditionally we've supported everything we get code for, but I think as we're
moving forward we can slowly raise the bar for the greater good. Since there
are many good alternatives, there's no reason to keep suggesting alternatives
that don't pass muster.

I'm not sure we can set strict rules just yet, but it would be aweseome to for
example require that the curl test suite works with all TLS backends or even
that they're all verified by CI builds (I think we're approaching a state
where both these are mostly true). That's a bit hard to enforce through-out
the entire collection though due to platform requirements etc.

For a while I've been wanting to be able to say that "all our 3rd party
dependencies are 100% CII Best Bractices[1] compliant" to make sure that the
projects we lean on are sound and awesome pillars in the open source
ecosystem, but I realize that we can't do that yet without having to cut off
too many useful libraries.

I think a good first step is to identify the weakest spots and question those
while we're taking steps to ensure the testing and CI situation improves from
the other end.

[1] = https://bestpractices.coreinfrastructure.org/

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html