
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<meta http-equiv="Content-Style-Type" content="text/css">

<title></title>

<meta name="Generator" content="Cocoa HTML Writer">

<meta name="CocoaVersion" content="1504.82">

<style type="text/css">

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}

p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}

p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}

p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica}

p.p5 {margin: 0.0px 0.0px 16.0px 12.0px; line-height: 15.0px; font: 13.0px Helvetica; color: #011892; -webkit-text-stroke: #000000}

p.p6 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 14.0px; font: 13.0px Helvetica; color: #011892; -webkit-text-stroke: #000000}

span.s1 {font-kerning: none}

span.s2 {font: 16.0px Helvetica; font-kerning: none}

</style>

</head>

<body>

<p class="p1">Hi Gelareh,</p>

<p class="p2"><br></p>

<p class="p1">Overall I think this pitch is a great move forward.<span class="Apple-converted-space"> </span></p>

<p class="p3"><br></p>

<p class="p4">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.</p>

<p class="p2"><br></p>

<p class="p1">Some inline comments below.</p>

<p class="p3"><br></p>

<p class="p4">-Bouke</p>

<p class="p2"><br></p>

<p class="p1">On 2017-04-06 16:16:51 +0000, Gelareh Taban via swift-evolution said:</p>

<p class="p2"><br></p>

<p class="p5"><span class="s1"># Problem</span></p>

<p class="p5"><span class="s1">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:</span></p>

<p class="p5"><span class="s1">- 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)</span></p>

<p class="p6"><span class="s1">- insecurity (using an unpatched or deprecated library such as OpenSSL on macOS)</span></p>

<p class="p3"><br></p>

<p class="p4">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.</p>

<p class="p3"><br></p>

<p class="p6"><span class="s1">- unmaintainablity (using non-standard or non-native libraries)</span><span class="s2"><br>

</span><span class="s1">- more complex code (using different APIs or code paths for each platform).</span><span class="s2"><br>

<br>

</span><span class="s1">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.</span><span class="s2"><br>

<br>

</span><span class="s1"># Design goals</span><span class="s2"><br>

<br>

</span><span class="s1">We came up with the following design goals for a solution:</span><span class="s2"><br>

<br>

</span><span class="s1">- Provide a consistent and unified Swift interface so that the developer can write simple, cross-platform applications;</span><span class="s2"><br>

</span><span class="s1">- Don't implement new crypto functionality and instead use existing functions in underlying libraries;</span><span class="s2"><br>

</span><span class="s1">- Plug-n-play architecture which allows the developer to decide on underlying security library of choice, e.g., OpenSSL vs LibreSSL;</span><span class="s2"><br>

</span><span class="s1">- Library should be agnostic of the transport mechanism (e.g., socket, etc), whilst allowing for both blocking and non-blocking connections;</span><span class="s2"><br>

</span><span class="s1">- Developers should be able to use the same TLS library for both client and server applications.</span></p>

<p class="p3"><br></p>

<p class="p4">+1</p>

<p class="p3"><br></p>

<p class="p4">Additionally I'd like to see and API that:</p>

<p class="p3"><br></p>

<p class="p4">- is designed for "ease of use"</p>

<p class="p4">- is strong typed</p>

<p class="p4">- integrates well with Foundation (DispatchQueue)</p>

<p class="p4">- fosters good performance (threading)</p>

<p class="p3"><br></p>

<p class="p6"><span class="s1"># Proposal</span><span class="s2"><br>

</span><span class="s1">(...)</span></p>

<p class="p3"><br></p>

<p class="p4">I'm not deeply familiar with the topic, so no comments on this part.</p>

</body>

</html>