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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
