[swift-server-dev] Crypto Library

[Helge Heß]

On 8 Nov 2016, at 16:45, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
> Whilst there's legitimate debate on the use of C vs. Swift for HTTP parsing, I think the situation for the security libraries in general is more clear.

This is really a bit off topic but I disagree with that. Either you:
a) are OK with C libs and deal with it
b) deal with C libs as a temporary measure but the goal is Swift
c) reject C libs from the start

I don’t see why you would accept OpenSSL as a C lib but can't accept http_parser or expat. That just doesn’t make any sense to me.
The reasoning seems to be more like: if it is non-trivial / means work and can’t be written by a rookie in a week, we can deal with C. But if it _is_ a trivial project it has to be Swift, because its secure and fast and beautiful etc (NIH). Though the exact opposite would bring sense into the reasoning: if Swift is more secure and faster, you should approach replacing the _complex_ C projects to gain better quality and performance, not the simple ones. Go figure :-)


> We've effectively got four choices on how to do the underlying implementation of the security APIs:
> 	• Use OpenSSL/LibreSSL everywhere

A major reason to use xyzSSL instead of CC on macOS is that macOS is primarily a dev environment for server side Swift development. Presumably the majority of (server) deployments will be on Linux or BSD, not on macOS. That is a big incentive to keep the environments as similar as possible, and CC and xyzSSL are really different on many levels.

The other side of the coin is that a lot of the stuff also makes sense on the client ("The challenge is iOS devices"). But that is not really the scope of this group?! :-) Maybe leave that to a server-side-Swift-on-the-client once we got the first part, server-side-Swift, working?

Anyways: Someone may correct me, but I think the real deal breaker is that CC doesn’t operate in NIO environments and hence is out of discussion for anything but dev/prototyping environments in the first place?


> 	• Create a pure-Swift implementation
> The implementation of OpenSSL is ~350K lines of code

That again, you really like LoC :-) Apple did CC from scratch so presumably they could do java.security for Swift from scratch. Does it make sense? If it is sustainable (proper resources assigned) maybe yes, if not, no.

I think a Swift TLS implementation is not going to come to life unless Apple (or another big player with the resources to actually maintain a project like this) invests in that. Likely? Probably not, though java.security (as well as other pure-Java things) did actually happen.

For practical purposes I can’t rely on this :-) As CC on Linux/BSD seems pretty unlikely (maybe if shipping with Swift?) either OpenSSL or LibreSSL has to be part of it.


Summary: I think option 1) (“Use OpenSSL/LibreSSL everywhere”) is the way to go for _this_ effort. Yes, some/all of the software also makes sense on iOS/macOS (and hence CC) but that looks like an entirely different effort to me, not “server side swift” aka Xserve.

hh