[swift-evolution] [Pitch] Cross-platform Swift TLS library

[Bouke Haarsma]

Hi Gelareh,

Overall I think this pitch is a great move forward. 

I've found that this is already resulting in some incompatibilities 
trying to combine rather complex Swift projects. I recently worked on 
integrating Kitura-Net, which uses BlueCryptor as a wrapper over both 
CommonCrypto / OpenSSL. I was delighted by BlueCryptor, as it proved to 
be a somewhat drop-in replacement for my custom CommonCrypto overlay. 
Seeing that this pitch moves along the same lines, I'm all for.

Some inline comments below.

-Bouke

On 2017-04-06 16:16:51 +0000, Gelareh Taban via swift-evolution said:

> # Problem
> Since there is currently no standard Swift SSL/TLS library that is 
> compatible on both Apple and Linux, Swift projects use their TLS 
> library of choice (such as OpenSSL, LibreSSL, Security framework, etc). 
> This results in:
> - fragmentation of the space as well as incompatibility of project 
> dependencies if more than one security package is needed by different 
> modules (a project cannot have both OpenSSL and LibreSSL in its 
> dependency graph)
> - insecurity (using an unpatched or deprecated library such as OpenSSL 
> on macOS)

This is even more true for Homebrew which refuses to link OpenSSL as 
those links might confuse the OS to link to the system's library 
instead (which is even more outdated). There's quite a bit incorrect 
"advice" floating around on how to create those symlinks.

> - unmaintainablity (using non-standard or non-native libraries)
> - more complex code (using different APIs or code paths for each platform).
> 
> So we want to propose a standard set of protocols that define the 
> behavior of the TLS service and how the application and the server and 
> networking layers beneath it interact with the TLS service. What 
> complicates this pitch is that the Swift in server space is new and 
> none of the interfaces have yet been defined, so this is really a work 
> in iteration.
> 
> # Design goals
> 
> We came up with the following design goals for a solution:
> 
> - Provide a consistent and unified Swift interface so that the 
> developer can write simple, cross-platform applications;
> - Don't implement new crypto functionality and instead use existing 
> functions in underlying libraries;
> - Plug-n-play architecture which allows the developer to decide on 
> underlying security library of choice, e.g., OpenSSL vs LibreSSL;
> - Library should be agnostic of the transport mechanism (e.g., socket, 
> etc), whilst allowing for both blocking and non-blocking connections;
> - Developers should be able to use the same TLS library for both client 
> and server applications.

+1

Additionally I'd like to see and API that:

- is designed for "ease of use"
- is strong typed
- integrates well with Foundation (DispatchQueue)
- fosters good performance (threading)

> # Proposal
> (...)

I'm not deeply familiar with the topic, so no comments on this part.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/2aa3a6fe/attachment.html>