chriskohlhoff / asio

Asio C++ Library
http://think-async.com/Asio
4.73k stars 1.2k forks source link

OpenSSL alternatives #1343

Open serfcity opened 11 months ago

serfcity commented 11 months ago

OpenSSL have got a lot of security bugs. When there are alternatives it's good. So, what about LibreSSL and GNUTLS support? GNUTLS for boost asio I have found here: https://github.com/paullouisageneau/boost-asio-gnutls Can this code be merged?

Delta-dev-99 commented 10 months ago

Disclaimer: This is only my opinion. I'm not, nor I have been (as of the time of writing) involved in the development of ASIO In short: Merging would be a bad idea and supporting multiple security libraries is unfeasible.

Supporting multiple security libraries is beyond the scope of ASIO. There is just that much effort that can be put into the development of the library, which would get diluted in supporting a possibly growing set of libraries and keeping updated that support. Building separate libraries over ASIO to support specific security alternatives is probably a good approach. That way, the efforts are focused where they are wanted/needed (i.e. if there is enough people that want a specific library, someone will probably start writing it) I believe ASIO should have never included SSL/TLS support, but focus instead on the core mechanisms of reading/writing asynchronously, where there's still ground for improvement. Asynchronous SSL/TLS support with ASIO would have then been implemented on a separate library. Modularization is a good thing, for many reasons. Perhaps the best approach to satisfying your concern would be to standardize an API/ABI for the TLS protocol (not an easy task). That way you could write generic code that would work with any TLS library, perhaps with small tweaks. You would then be able to easily select the desired implementation at link time. But, and this is a recurrent reason in my experience, more often that not, things just kinda sorta work as they are and people don't really care much about perfection, or in this case, having all the alternatives available and at hand. It's sometimes easy to devise the changes needed to make things the way they should be, but, as with our "best approach" above, the scale of the enterprise usually gets quickly out of hand. We are surrounded by LOTS of examples of this happening. Just consider that the commonplace x86_64 processors we use today still start under at least 2 levels of legacy compatibility modes.