On Thu, 6 Nov 2014, Daniel wrote:
> Looking over libtls it struck me that this is the best-designed TLS
> API I've ever seen, so it was a bit disheartening to look at the code
> and find that it was mainly just wrapping libssl and abstracting away
> its fragile, haphazard design choices. Though even just this is
> obviously already an unconditional good, are there plans for enough of
> libssl to be split off, cleaned up, and rolled directly into libtls so
> that the libtls -> libssl dependency can be broken for good?
The short answer is yes, that's the long term ideal.
The longer answer is that there is still a huge amount of software that uses
libssl and even if we took the time to write a brand new TLS implementation,
it would be of little benefit until everything started using it. The amount
of effort required to implement a new TLS from scratch is significant. Same
goes with porting existing software to use it.
For the time being we're far better off investing time into fixing libssl as
much as we possibly can (while being held to its existing API), while also
providing a new TLS API that things can start using now. Hopefully we'll
eventually get to the point where libtls stands on its own...
--
"Action without study is fatal. Study without action is futile."
-- Mary Ritter Beard
