Ah right, I misremembered, it uses libressl, though, right? My point was more that it cannot use a library provided by the OS.
LibreSSL or OpenSSL, whatever it can find.
On Apple platforms that's absolutely correct.
They plan to back port OpenSSL 1.1.1 on 18.04 (there is already an SRU open), but the process is very slow. If we are lucky, maybe TLS 1.3 will be available on 18.04 before 2020.
And I think LibreSSL didn't even start to work on TLS 1.3.
I would really appreciate to don't have to bother with this kind of details when I have to deploy some apps, so I'm very exited about having BoringSSL embedded in Swift NIO.
Speaking of a pure Swift TLS implementation. There is my SwiftTLS library, which is admittedly more a proof of concept, but nonetheless implements most of TLS 1.2 and 1.3. It's nowhere near ready for prime time of course, but could be a good starting point if anyone ever wants to pursue this.
Imho SSL isn't the biggest blocker not to use Swift for server stuff, so I like the idea of bundling a pure Swift solution that might not be suited for productive use, but more fun to play with (assuming it would still be possible to switch to an established lib easily).
Even if it's impossible to write a bulletproof implementation with Swift 5, I think it's good to start aiming for that goal now: Workarounds have a tendency to persist, and if Swift wants to be a general purpose language, having a constant reminder that there are topics where we can't compete with C yet might have a better effect than settling with an external lib.
This isn’t either-or. We can ship a production ready library today and be able to adopt an alternative tomorrow. swift-nio-ssl exposes approximately zero APIs that are tied to its underlying TLS implementation, and will continue to do so.
Again, I stress that we should not let the perfect be the enemy of the good. We can build something good now, and be useful now, while we buy time for alternative implementations to improve and mature.
While the discussion here has quieted down recently, I've had some personal conversation with participants in this thread that indicate that there are still people thinking over their positions on this issue. Given that there's no particular urgency here, I propose to give people the holiday period to mull over their positions on this issue and continue the discussion.
We'll try to come to a final decision in the first or second week of January 2019.
Overall I'm in favour of this.
On the one hand, this is a problem that every program that links against system libraries has to tackle, and we do it all the time using
if #available for libraries like
Foundation. In that sense it's not entirely unreasonable to tell those system administrators that they have to update the OS to patch security holes or take advantage of newer features like HTTP2/3.
On the other hand, it sounds like
libssl has been a bit sloppy about API and ABI compatibility. In the absence of a stable alternative library, it makes sense to bundle our own implementation.
I would love to see us expose a public, Swift interface to the SSL/crypto functions one day, but that's a whole other thing.
I'm a bit concerned about how narrowly BoringSSL might be focused on their own needs and how closed it is to external needs/contributions. We can only try it and see - we'd still have the option to change the implementation we use if problems arise.
Also - Apple has open-sourced recent versions of many crypto frameworks (CommonCrypto, Security.framework, coretls). I'm not exactly sure how they all fit together, but is there not a complete/nearly-complete implementation there which we could use? I guess that interface is stable enough that we could create a nice Swift wrapper for it.
And system administrators would be more than happy to update there system, but they don't choose what packages are released on what system version. Today, you may ask Ubuntu TLS administrators to update to OpenSSL 1.1.1 to use TLS 1.3, but that version is not released yet on Bionic, and system administrator can't do much about it.