├── CONTRIBUTING.md ├── LICENSE ├── README.md └── meetings ├── .gitkeep ├── http ├── 2016-11-21 │ └── minutes.md ├── 2016-12-12 │ └── minutes.md ├── 2017-03-14 │ └── minutes.md └── 2017-04-06 │ └── minutes.md ├── networking └── 2016-11-04 │ └── minutes.md └── security ├── 2016-11-03 └── minutes.md ├── 2016-12-14 └── minutes.md ├── 2017-02-06 └── minutes.md └── 2017-04-21 └── minutes.md /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | By submitting a pull request, you represent that you have the right to license 2 | your contribution to Apple and the community, and agree by submitting the patch 3 | that your contributions are licensed under the [Swift 4 | license](https://swift.org/LICENSE.txt). 5 | 6 | --- 7 | 8 | Before submitting the pull request, please make sure you have tested your 9 | changes and that they follow the Swift project [guidelines for contributing 10 | code](https://swift.org/contributing/#contributing-code). 11 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | 204 | 205 | ### Runtime Library Exception to the Apache 2.0 License: ### 206 | 207 | 208 | As an exception, if you use this Software to compile your source code and 209 | portions of this Software are embedded into the binary product as a result, 210 | you may redistribute such product without providing attribution as would 211 | otherwise be required by Sections 4(a), 4(b) and 4(d) of the License. 212 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Status 2 | 3 | :warning: This repository contains historical information about the Server APIs Work Group. This work is now being progressed in the [Server](https://forums.swift.org/c/development/server) category on the Swift Forums. All interested parties are invited to participate on the forums. 4 | 5 | ## Server APIs Work Group 6 | 7 | The Server APIs Work Group is responsible for steering the [Swift Server APIs](http://swift.org/server-apis/) project, which is an evolving set of Swift libraries developed as part of the Swift open source project to provide fundamental capabilities for building server-oriented software. 8 | 9 | The work group consisting of a core team, stakeholders from the server-side Swift community, and anyone who wants to get involved. The work group consists of three roles: core team member, stakeholder and contributor. Participants may have more than one role in the work group. 10 | 11 | Everyone is welcome to contribute to the Server APIs Work Group through participating in a range of activities including joining as a stakeholder, participating in design discussions, asking or answering questions on the mailing lists, reporting or triaging bugs or by submitting pull requests to the project(s) for implementation or tests. 12 | 13 | ### Current Focus Areas 14 | The work group is initially focussing on the creation of API proposals for base networking, security/encryption and HTTP parsing: 15 | 16 | * **Base Networking**: Provide a portable interface for low level socket based network based I/O, including TCP/IP and UDP protocols, IPv4 and IPv6 support and domain name resolution. Support should be provided to create and use both synchronous and asynchronous non-blocking connections. 17 | 18 | * **Security and Encryption**: Provide common cryptographic constants and cyphers along with keychain and certificate management, and SSL/TLS based secure transport. This must integrate with the base networking support to provide secure sockets, and with the HTTP parsing library to provide HTTPS support. 19 | 20 | * **HTTP and WebSockets**: Provide low level HTTP parsing, including HTTP, HTTP/2 and WebSocket support making it possible, in conjunction with the security and networking APIs, to create secure HTTP and WebSocket servers. 21 | 22 | ### Steering Team 23 | Analogous to the primary Core Team for Swift, the work group has a steering team that is responsible for providing overall technical direction, ensuring co-ordination both between the various API efforts (for example around Network, Security and HTTP integration for HTTPS) and with the wider Swift Core Libraries and language. Membership of the steering team is contribution based and is expected to evolve over time. 24 | 25 | The initial steering team consists of: 26 | 27 | * Chris Bailey ([@seabaylea](https://github.com/seabaylea), IBM Kitura) 28 | * Logan Wright ([@LoganWright](https://github.com/LoganWright), Vapor) 29 | * Paulo Faria ([@paulofaria](https://github.com/paulofaria), Zewo) 30 | * Steve Algernon ([@salgernon](https://github.com/salgernon), Apple) 31 | 32 | ### Stakeholders 33 | The work group also has stakeholders who represent server-side frameworks or applications. They are responsible for providing early input on use cases and API design as part of the iterative design and implementation process, and to adopt the new APIs into their frameworks. 34 | 35 | Joining and leaving the work group as a stakeholder is a straightforward process. The only requirement is to raise a Pull Request to add or remove your name from the stakeholder list in this project, which will act to add or remove you from invites to formal work group discussions. 36 | 37 | The initial stakeholders consists of (alphabetically): 38 | 39 | * Ah Shone ([@tasktinkle](https://github.com/tasktinkle), Baidu) 40 | * Alex Blewitt ([@alblue](https://github.com/alblue), Apple) 41 | * Alfredo Delli Bovi ([@adellibovi](https://github.com/adellibovi)) 42 | * Andrew Dunn ([@Andrew-Dunn](https://github.com/Andrew-Dunn)) 43 | * Bas Broek ([@basthomas](https://github.com/basthomas)) 44 | * Ben Cohen ([@airspeedswift](http://github.com/airspeedswift), Apple) 45 | * Billy Tobon ([@billyto](http://github.com/billyto), Rent the Runway) 46 | * Carl Brown ([@carlbrown](http://github.com/carlbrown), IBM) 47 | * Cătălin Stan ([@thecatalinstan](https://github.com/thecatalinstan), Criollo) 48 | * Damian Kolakowski ([@glock45](https://github.com/glock45), Swifter & swiftx) 49 | * Dan Appel ([@danappelxx](https://github.com/danappelxx), Zewo) 50 | * Daniel Dunbar ([@ddunbar](https://github.com/ddunbar), Apple) 51 | * Danielle Tomlinson ([@dantoml](https://github.com/dantoml), Jay & Other OSS) 52 | * David Ask ([@davidask](https://github.com/davidask), Zewo) 53 | * David Sperling ([@dsperling](https://github.com/dsperling), Smith Micro) 54 | * Eleftherios Laskaridis ([@laskaridis](https://github.com/laskaridis), eTravel) 55 | * Emanuel Guerrero ([@eman6576](https://github.com/eman6576)) 56 | * Farzad Nazifi ([@euwars](https://github.com/euwars), boon) 57 | * Gelareh Taban ([@gtaban](https://github.com/gtaban), IBM) 58 | * Gianluca Tranchedone ([@gtranchedone](https://github.com/gtranchedone)) 59 | * Gregor Milos ([@gmilos](https://github.com/gmilos), Apple) 60 | * Gwynne Raskind ([@gwynne](https://github.com/gwynne)) 61 | * Ian Partridge ([@ianpartridge](https://github.com/ianpartridge), IBM) 62 | * J. Morgan Lieberthal ([@baberthal](https://github.com/baberthal)) 63 | * Jack Lawrence ([@jackhl](https://github.com/jackhl), Apple) 64 | * Jacopo Andrea Giola ([@JGiola](https://github.com/jgiola)) 65 | * Jason Toffaletti ([@toffaletti](https://github.com/toffaletti), Apple) 66 | * Joannis Orlandos ([@joannis](https://github.com/joannis), OpenKitten) 67 | * Johannes Weiß ([@weissi](https://github.com/weissi), Apple) 68 | * John Lin ([@johnlinvc](https://github.com/johnlinvc)) 69 | * Jonathan Thornton ([@jonblatho](https://github.com/jonblatho), Loop Weather Services) 70 | * Kelvin Çobanaj ([@kelvincobanaj](https://github.com/kelvincobanaj)) 71 | * Kuan Huang ([@widehuang](https://github.com/Widehuang), Baidu) 72 | * Kyle Jessup ([@kjessup](https://github.com/kjessup), Perfect) 73 | * Laurent Gaches([@lgaches](https://github.com/lgaches)) 74 | * Marcin Kliks ([@vi4m](https://github.com/vi4m), Zewo) 75 | * Max Desiatov ([@explicitcall](https://github.com/explicitcall), Astrocat) 76 | * Maxim Veksler ([@maximveksler](http://github.com/maximveksler), Sugar So What) 77 | * Ludovic Dewailly ([@ldewailly](https://github.com/ldewailly), Apple) 78 | * Luke Hiesterman ([@gravisman](https://github.com/gravisman), Apple) 79 | * Marc Hoffman ([@dwarfland](https://github.com/dwarfland), RemObjects Software, Elements Compiler) 80 | * Michael Chiu ([@michael-yuji](https://github.com/michael-yuji), SX0) 81 | * Nic Jackson ([@nicholasjackson](https://github.com/nicholasjackson), notonthehighstreet.com) 82 | * Patrick Bohrer ([@pbohrer](https://github.com/pbohrer), IBM) 83 | * Phil J. Łaszkowicz ([@siilime](https://github.com/siilime), Omnijar Studio) 84 | * Piers Mainwaring ([@piersadrian](https://github.com/piersadrian)) 85 | * Ricardo Borelli ([@rabc](https://github.com/rabc), Zewo) 86 | * Rick Mann ([@jetforme](https://github.com/jetforme), Latency: Zero, LLC) 87 | * Robert Dickerson ([@rfdickerson](https://github.com/rfdickerson), IBM Kitura) 88 | * Robert Payne ([@robertjpayne](https://github.com/robertjpayne), Zewo) 89 | * Ryan Collins ([@rymcol](https://github.com/rymcol)) 90 | * Sahand Nayebaziz ([@sahandnayebaziz](https://github.com/sahandnayebaziz), Hypertext) 91 | * Sam Liu ([@ontouchstart](https://github.com/ontouchstart)) 92 | * Sasha Milic ([@SashaMilic](https://github.com/sashamilic), OpenRatio) 93 | * Scott Lessans ([@slessans](https://github.com/slessans), Nourish Technology) 94 | * Stevey Brown ([@Steveybrown](https://github.com/steveybrown)) 95 | * Tanner Nelson ([@tannernelson](https://github.com/tannernelson), Vapor) 96 | * Thiago Holanda ([@unnamedd](https://github.com/unnamedd), Zewo) 97 | * Thomas Catterall ([@swizzlr](https://github.com/swizzlr)) 98 | * Thomas Paul Mann ([@thomaspaulmann](https://github.com/thomaspaulmann), Swish) 99 | * Tim Burks ([@timburks](https://github.com/timburks), Google) 100 | * Tom Doron ([@tomerd](https://github.com/tomerd), Apple) 101 | * Tripta Gupta ([@neurosaurus](https://github.com/neurosaurus), Capital One) 102 | * Tyler Cloutier ([@cloutiertyler](https://github.com/cloutiertyler), Edge) 103 | * Tyler Stromberg ([@AquaGeek](https://github.com/AquaGeek)) 104 | * Veck Hsiao ([@fbukevin](https://github.com/fbukevin), Sanity) 105 | * Wassim Seifeddine ([@wassimseif](https://github.com/wassimseif)) 106 | * Yuki Takei ([@noppoMan](https://github.com/noppoMan), Slimane) 107 | 108 | 109 | ### Additional Information 110 | More information can be found in the [Server APIs pages](http://swift.org/server-apis/) of [swift.org](http://swift.org), or by posting to the [swift-server-dev](https://lists.swift.org/mailman/listinfo/swift-server-dev) mailing list. 111 | -------------------------------------------------------------------------------- /meetings/.gitkeep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swift-server/work-group/0b584cca162458b6758de39836405ac4c5334f4c/meetings/.gitkeep -------------------------------------------------------------------------------- /meetings/http/2016-11-21/minutes.md: -------------------------------------------------------------------------------- 1 | # HTTP sub-team kick-off 2 | 3 | ### Initial Agenda: 4 | * Introductions 5 | * Goals 6 | * Development process overview 7 | * Next Steps 8 | 9 | ### Attendees: 10 | * Chris Bailey 11 | * Alex Blewitt 12 | * Ryan Collins 13 | * Ben Cohen 14 | * Sam Liu 15 | * Shmuel Kallner 16 | * Tyler Stromberg 17 | * Robert F. Dickerson 18 | * Logan Wright 19 | * Tanner Nelson 20 | * David Sperling 21 | * Kuan Huang 22 | * Johannes Weiss 23 | 24 | ### Minutes: 25 | 26 | _How are we going to interface these things together, ie, how HTTP sits on networking?_ 27 | * Concurrency between now and at least Swift 5 is going to be Dispatch based. From Swift 5 and onwards there may be a new concurrency model. We’ll need to transition at that time. 28 | * Assuming Dispatch gives us the same problem as elsewhere when migrating to a new concurrency model, so we share the problem/solution 29 | * HTTP APIs should be available separately from networking/concurrency, as well as a combined. 30 | 31 | _What model are we going to use? Should request/response be value types or reference types?_ 32 | * The Open Swift effort hit a few issues over models, and disagreements on the HTTP models. Reference vs. value types for the request class. 33 | * There’s some lessons learned from the openswift / swiftx experience - should be reviewed in the next meeting. 34 | 35 | 36 | _HTTP 1.x vs HTTP/2 support_ 37 | * HTTP2 is going to be unavoidable, so we should probably include it in the first version so we don’t risk breaking APIs 38 | 39 | 40 | _Use cases:_ 41 | * HTTP on server only? What about on the client for device -> device? 42 | * Foundation has a dependency on libcurl, we’d ideally help to allow that to be removed. 43 | 44 | 45 | _Reference vs. value-types_ 46 | * (Logan) Vapor had success with reference types rather than value types 47 | * (Shmuel) Kitura had issues moving NSData -> Data, resulting in a ~20% performance reduction. Middlewares work better with reference types 48 | * (Ben C) We should separate semantics from performance. 49 | * In general we are going to be passing request/response around. The question is really about whether the caller needs access to the changes from the callee. 50 | * Middleware adds features into the request - callee returns to caller, and does so in a chain 51 | 52 | 53 | _Encoding issues:_ 54 | * Header as ASCII vs. content-body in other encodings 55 | * At the lowest level, we’ll just be providing bytes - the framework can deal with the contents? 56 | 57 | _Use of C vs pure Swift parsing:_ 58 | * Swift “port” of the Node.js c-http parser done by Dave Sperling 59 | * https://github.com/smithmicro/HTTPParser 60 | * As close to the C version as possible - line for line transliteration. 61 | * Use of UnsafePointer is already in place 62 | * Significant time is still being spent in reference counting - would benefit from an expert in Xcode Instruments reviewing the codebase. 63 | * Vanilla c-http parser achieved 700K requests/sec, vs 500K for the Swift "port" - so c-http is currently ~40% faster. 64 | * Using pure-Swift has the potential to enables deeper level of inlining, so may ultimately give greater performance 65 | * Helge Heß has done similar C vs Swift implementation comparisons: 66 | * https://github.com/helje5/http-c-vs-swift/ 67 | * c-http parser almost exclusively uses macros to inline everything. 68 | * Tried to replicate using the unofficial `@inline(__always)` which improves perf quite a bit. BUT it has also been very fragile, i.e. the Swift 3 compiler would often just crash etc. 69 | * Found similar results: c-http parser us much faster than the Swift implementation. 70 | * Using Swift code may also enable a wider set of contributors/maintainers for the code from the swift community (vs. the existing community working on the C code). 71 | * However if we reuse then it's something the Swift community needn't maintain at all. 72 | * Does HTTP2 parsing affect our choice? 73 | 74 | 75 | -------------------------------------------------------------------------------- /meetings/http/2016-12-12/minutes.md: -------------------------------------------------------------------------------- 1 | # HTTP stream meeting 1 2 | 3 | 4 | ### Initial Agenda: 5 | * Current discussion status roundup 6 | * Value Types vs. Reference Types 7 | * Use of NSHTTPURLRequest/Response 8 | * Experiences of adding HTTP/2 support to Node.js 9 | 10 | ### Attendees: 11 | * Chris Bailey 12 | * Alex Blewitt 13 | * Alfredo Delli Bovi 14 | * Ben Cohen 15 | * Michael Chiu 16 | 17 | ### Minutes: 18 | 19 | _C vs Swift Implementations:_ 20 | 21 | Some current implementations: 22 | 23 | | Framework | HTTP 1.x Parser | HTTP/2 Parser | Request Type | Response Type | Notes | 24 | |-----------|-----------------|---------------|--------------|---------------|-------| 25 | | Kitura | c-http parser | N/A | Class | Class | | 26 | | Perfect | c-http parser(1)| Swift parser | Class | Class |(1) HTTP 1.x parser used to be pure Swift | 27 | | Swifter | Swift parser | N/A | Class | Enum | | 28 | | Vapor | Swift parser | N/A | Class (2) | Class (2) |(2) Switched to classes from structs | 29 | | Zewo | c-http parser | N/A | Struct (3) | Struct (3) |(3) Class used for stream backed Body fields | 30 | | spartanX | Swift parser | N/A | Struct | Struct | | 31 | 32 | Notes: 33 | (1) Perfect originally implemented their own HTTP 1.x parser in Swift, but switched to using the c-http parse from Node.js 34 | (2) Vapor originally implemented HTTP request and response as structs, but switch to using classes 35 | (3) Zewo uses structs for HTTP request and response, however the Body field is an enum. Where the enum is a stream, it is backed by a class. 36 | 37 | _Let's assume we're going to re-use existing C libraries for HTTP 1.x and HTTP/2:_ 38 | * When doing a new implementation of existing functionality the new implementation is inherently going to have more bugs, simply due to the lack of available time in the field and being "battle tested" (c.f. Apache Harmony vs existing Java Class Library code) 39 | * There's also the additional effort to maintain and bug fix, and keep up with any new enhancements 40 | * In terms of performance, the only scope for a Swift implementation to really exceed a C implementation is likely around inlining (across the Swift/C boundary) and any type conversions (ie, across the C/Swift API boundary). 41 | * This allows us to concentrate efforts on developing the right Swift API - we can always subsequently go back and revisit the underlying implementation. 42 | 43 | **However...** 44 | * We have to make sure that the underlying C API does not influence the Swift API surface: 45 | * Things like memory management from C driving the design etc 46 | * We could potentially mitigate this by ensuring the API would also make sense if applied to a non-Swift implementation (eg. that from Vapor or Swifter) as a one-off verification. 47 | * We should be more wary of non-battle tested C APIs. We should look to see how much usage the "nghttp2" library for HTTP/2 is getting to see if it falls into this category. 48 | * Licensing issues were raised around using the c-http parser from Node.js as its MIT licensed code. 49 | * There are no legal issues preventing the use of MIT licensed code in Apache 2 projects, and its already done elsewhere in Swift (libkqueue for example). We should follow up with the Core team to understand if there's any issues. 50 | 51 | 52 | _Value types vs Reference Types:_ 53 | * We should probably use the term “semantics” rather than types, because behaviors and types are separate. 54 | * There's a strong desire to reuse the Foundation types, so we should focus in the short term in making sure that they are right. 55 | * Foundation was originally reference only, and we’ve started to add value semantics, but this is not complete in all cases. Rather than looking at where Foundation is right now, we should look at what types they should eventually be. 56 | * Really we need there to be a conversation between Ben and Tony Parker/Philippe Hausler to determine the direction for the Foundation types. 57 | * Currently we believe that, in general, value semantics make sense, with the use of `inout` for middlewares, but there is the question around the mixing of reference and value semantics (ie, a struct wrapping a stream as a reference type). 58 | * Building a map/flow diagram of how a request is handled and used by middlewares will help to model the interactions with requests/responses, and show better what semantics should be used. 59 | 60 | _Experiences of adding HTTP/2 support to Node.js_ 61 | * Significant progress has been made in Node.js to adopt the `nghttp2` library 62 | * Presentation from James Snell at Node Interactive is online: 63 | https://www.youtube.com/watch?v=7uNGKCao8gA&t=1157s&list=PLfMzBWSH11xYaaHMalNKqcEurBH8LstB8&index=19 64 | 65 | 66 | ### Next steps: 67 | * Include Tony Parker and Philippe Hausler in a discussion on the direction for request/response types in Foundation 68 | * Discuss the use of MIT licensed code with the Swift Core Team 69 | * Build a flow diagram for request handling and the use of middlewares 70 | * Start to build an outline proposal for the HTTP parsing library for use as a Swift Evolution "pitch" 71 | -------------------------------------------------------------------------------- /meetings/http/2017-03-14/minutes.md: -------------------------------------------------------------------------------- 1 | # HTTP stream meeting 2 2 | 3 | 4 | ### Initial Agenda: 5 | * Review of draft HTTP API Pitch 6 | * https://docs.google.com/document/d/1ErHA8RXLiTGvOPHNY0KtbWCvwR1IUz_2ffi7CxCUo_4/edit 7 | * Discussion of key points: 8 | * Use of URLRequest/Response 9 | * Value Types vs. Reference Types 10 | 11 | ### Attendees: 12 | * Chris Bailey 13 | * Ben Cohen 14 | * Carl Brown 15 | * Stevey Brown 16 | * Tony Parker 17 | * Gregor Milos 18 | * Shmuel Kallner 19 | * Alex Blewitt 20 | * Allen 21 | * Chuck Goddard 22 | * George 23 | * Johannes Weiss 24 | * Ludovic Dewailly 25 | * Marcin Kliks 26 | * Nasser Ebrahim 27 | * Steve Algernon 28 | * Michael Papp 29 | * Thomas Catterall 30 | 31 | ### Minutes: 32 | 33 | _Use of value types vs. reference types for request and response_ 34 | * General consensus is in favour of using a value types for request and response. 35 | * The argument that these should be references as they are passed around and mutated really doesn’t hold 36 | * It should be noted that the reason why there is still NSURLRequest/Response (reference types) was because a subclass exists, rather than the intend that they should be reference types. 37 | * The use of value types will help with reference cycles in closures (like middlewares) which you otherwise need to use weak self for. 38 | * Should also help with reducing some of the ARC overhead 39 | * ARC overhead won’t necessarily be removed if the struct/value types has references inside it - and the body data is really a stream which has to be a reference type 40 | * In Foundation, request and response is just the headers, the body data is a side stream so they can be separated 41 | * This is done URLSession (as with downloadTask) into a file or a stream (and the same would be true for responses). 42 | * Can be thought of like sequence, which is a value type for which you can get an iterator which is a reference type 43 | * Separate experience from Johannes is creating a framework which has request/response separate from the body stream. 44 | * Request and response are value types 45 | * Handler provides a BodyProcessor which is called when chunks of data become available 46 | * This is especially important when the client is using Chunked transfer encoding, which some frameworks currently don’t attempt to handle. 47 | * General consensus in separating the request and response headers (metadata) away from the body, which can be handled separately either by a handler API or a closure. 48 | * How do we handle HTTP trailers if we separate headers and body stream? 49 | * Trailers are in the body stream and arrive after the headers are complete, but add to the headers 50 | * These aren’t well specified, and probably need to be handled by whatever is processing the stream anyway. 51 | 52 | _Use of Foundation based types for request and response_ 53 | * It’s accepted that the Foundation types don’t match the requirements for general request and response types today as they're designed for a specific set of use cases. 54 | * We should figure out what the “right answer” should be for Swift (without regard to Objective-C compatibility), and then see how that fits into the existing types 55 | * There’s definitely scope to extend or modify the existing types 56 | * But we’d need a migration plan so that existing users aren’t broken 57 | 58 | _Next Steps:_ 59 | * Update draft pitch with feedback 60 | * Define the required contents for the request and response types 61 | * How should be store the header metadata itself? 62 | * Should data be fully processed eagerly or lazily? 63 | * How do we handle the various header parsing rules? 64 | * Define approach to handling the body stream separately to the header metadata 65 | 66 | -------------------------------------------------------------------------------- /meetings/http/2017-04-06/minutes.md: -------------------------------------------------------------------------------- 1 | # HTTP stream meeting 4 2 | 3 | ### Time: Thursday April 6th 4 | * 7pm CET 5 | * 6pm UK 6 | * 1pm EST 7 | * 10am PST 8 | 9 | ### WebEx and Agenda/Minutes doc: 10 | 11 | WebEx: URL: https://ibm2.webex.com/ibm2-en/j.php?MTID=m69c1c150e3a3780f1308f0c529808ed9 12 | password: http 13 | 14 | Agenda: https://docs.google.com/document/d/1GTm7mJH2vCAK-Ts4M3t8C3boJ18XqiFnCRuyp55eKJE/edit?usp=sharing 15 | 16 | If you'd like to add anything to the agenda ahead of time, please update the agenda document in Google Docs. 17 | 18 | ### Initial Agenda: 19 | * Review Johannes’ proposal, which includes: 20 | * HTTPHeaders as a struct, Body (stream) as a class 21 | * Access to the Body stream using async callbacks 22 | * Link: To be added 23 | 24 | * Discussion points: 25 | * Use of struct for headers 26 | * Allows frameworks to be value-type based, or wrap in a class to be reference-type based 27 | * Sync vs. Async access to the body stream 28 | * Can we support both? 29 | * If not, should be be opinionated as state async, as Dispatch is the built-in concurrency approach? 30 | 31 | If you'd like to add anything to the agenda ahead of time, please update the agenda document in Google Docs. 32 | https://docs.google.com/document/d/1OoRTWOn6c1ssMl-OGZ2Gy2tYxCbHy-WHCXLcZy4-uTs/edit?usp=sharing -------------------------------------------------------------------------------- /meetings/networking/2016-11-04/minutes.md: -------------------------------------------------------------------------------- 1 | # Networking sub-team kick-off 2 | 3 | ### Initial Agenda: 4 | * Introductions 5 | * Goals 6 | * Development process overview 7 | * Next Steps 8 | 9 | ### Attendees: 10 | * Chris Bailey - IBM, Kitura and Swift.org stuff 11 | * William Dillon (hpux735) - Swift-ARM, embedded systems, mac, linux, etc 12 | * Alfredo Delli Bovi - contributions to Swift core. Background in Node.js/PHP 13 | * Steve Algernon - Apple, CF, CFNetwork, NSURLSession 14 | * Paulo Faria - Zewo 15 | * Thiago Holanda - Zewo, iOS Developer and Python. 16 | * Morgan Lieberthal - Mac / backend web developer 17 | * John Lin - iOS dev, Ruby, Python & Erlang 18 | * Illia Tykhonkov - iOS developer 19 | * Matt DeFoor - Condrey Corporation 20 | * Piers Mainwaring - Backend web dev 21 | * Tyler Stromberg – iOS/Mac dev; Ruby, Elixir, Go 22 | * Lasse Jansen - iOS/Mac developer 23 | * Bill Abt - IBM, Swift@IBM - Kitura, BlueSocket, BlueSSLService 24 | * Johannes Weiss - Apple, iCloud 25 | * Gregor Milos - Apple, iCloud 26 | * Scott Lessans - Full Stack/Robotics; nourish.ai 27 | * Ben Cohen - Swift standard lib @Apple 28 | 29 | ### Minutes: 30 | 31 | _Q) Don’t we just need a layer on POSIX? Or just the intent of the POSIX layer? How are developers going to use the APIs in the most effective way? Do they really need the low level APIs?_ 32 | * Devs really just want to use high level APIs that are focused on their use case. 33 | * We take the approach of building the high level APIs, and use that to inform us of what the lower level capabilities need to be? 34 | * A justification for lower-level APIs is the impedance mismatch between POSIX C API and Swift. This is especially evident in the variadic nature of fcntl, and the prevalence of bit-pattern casting of similar structs, such as sockaddr. 35 | 36 | * Some very low level stuff that missing: 37 | * Errno and error handling - might be a standard library thing (POSIX lib) 38 | * Swift-compatible implementations of fcntl and ioctl 39 | * Basic address processing: resolution, conversion, equality 40 | 41 | 42 | _Q) Whats the value of high level vs low level APIs?_ 43 | Example: Building an interface with an embedded system. The embedded system implements a proprietary mechanism using UDP multicast. This necessitated manually joining multicast groups, and sending and receiving multicast packets. 44 | An attempt was made to try to do it with Vapor's network code, but there were difficulties because of the usage assumptions in the Vapor code, such as private methods for managing internet address structures. To achieve what was required, the code had to be forked and modified. 45 | 46 | 47 | * We should be able to expose sockets at a fairly high level - I/O plus config plus policy. 48 | * But if the fuction a user needs is not there, they will have/need to “drop down” to lower level APIs. 49 | * Is that dropping down to platform specific C code, or to a “Swift” layer API? 50 | * Dropping down to a Swift layer more is desirable and safer. 51 | 52 | 53 | _Q) How do we deal with platforms that have additional capabilities?_ 54 | Does the user have to use C code there, or should we provide a way to have per-platform extensions? 55 | * Swift provides extensions… 56 | * Platform capability checking “#if os(...)” 57 | 58 | 59 | _Q) If we have high level abstractions, do we have to assume what the concurrency model is? 60 | If so, will that prevent other concurrency choices being made, or do we need to provide a lower level construct (as well) that allows you to chose your own model?_ 61 | * We can’t assume what the concurrency model is going to be yet - because those discussions are yet to happen. 62 | 63 | * We could provide APIs that build up in layers: 64 | * Lowest level - no assumptions on concurrency. File descriptor and use your own polling. Is blocking I/O and select() enough on this layer? 65 | * Start to bring in async model - Dispatch based for the “default” 66 | - Protocol based with a default implementation? 67 | * Higher level abstractions - based on what you’re trying to do. 68 | 69 | * APIs at the lowest layers are likely to be more concrete (as they are RFC specified) - although we have to decide how to make them “Swifty”. 70 | 71 | 72 | **Note:** We need to ensure that we use proper terminology in order to avoid confusion: 73 | * Async vs. Sync (API level) 74 | * Blocking vs. Non-blocking IO (Concurrency model level) 75 | 76 | Also, a nice, clear definition of what being more “Swifty” means is probably needed - at least one we can agree on. 77 | -------------------------------------------------------------------------------- /meetings/security/2016-11-03/minutes.md: -------------------------------------------------------------------------------- 1 | # Security sub-team kick-off 2 | 3 | ### Initial Agenda: 4 | * Introductions 5 | * Goals 6 | * Development process overview 7 | * Next Steps 8 | 9 | ### Attendees: 10 | * Chris Bailey - IBM, Kitura and Swift.org stuff 11 | * Cătălin Stan - Interested in Swift/server as of Swift 3. Background is Linux systems programming and Obj-C. Starting withing on a fast-cgi framework, then moved on to also include http 12 | * Johannes Weiss - Apple iCloud/Swift Server. 13 | * Gregor Milos - Apple iCloud/Swift Server. Building low level tools/frameworks 14 | * Alfredo Delli Bovi - contributions to Swift core. Background in Node.js/PHP 15 | * Tyler Stromberg - mostly working on client apps - BE stuff with Ruby, Elixir, Go 16 | * Luke Hiesterman - Apple in the security engineering team on security APIs 17 | * Piers Mainwaring - web & mobile dev in Swift. JavaScript/Ruby/Python on the BE. Worked on some home-rolled Swift server frameworks 18 | * Gelareh Taban - IBM, working on security for the Swift@IBM group 19 | 20 | ### Minutes: 21 | _Q) What are our intended timelines:_ 22 | * We really need to have a ”1.0” for Swift 4. Previews should/will be available way before that though. 23 | * We’re not constrained by Swift 4.0 though since we can release as packages. 24 | 25 | _Q) How important do we see that security is on the server side? Couldn’t you just put a reverse proxy in front?_ 26 | * You can if you put the proxy in the same container, so HTTPS isn’t/shouldn’t be a show stopper… 27 | * More important for outbound, as its needed for HTTPS requests of other services 28 | * However, code portability is a must. We want the API layer to be shared among different platforms - including iOS clients and Linux/macOS servers. The implementation doesn’t have to be the same in all cases, but the APIs should be (if at all possible). 29 | * There are going to be challenges though - we’ll need to do so in a way that doesn’t add significant overhead, and we don’t want you to have to use the Linux/server package on iOS clients. 30 | 31 | _Q) What level should the APIs be at? Should they be multi-purpose or implement specific (server) use cases_ 32 | ie, if I want to make a HTTP request, I don’t want to use a socket, I want to use a convenience API 33 | * We really want so start at the lowest level, building a multi-purpose API, to provide flexibility of use case. 34 | * Once we have that, we can build up one or more layers of more use case based APIs. 35 | 36 | _Q) Should be build in Swift vs reuse existing tech?_ 37 | * Ideally want to reuse existing components, so we don’t have to maintain complex code, deal with CVEs, etc. There’s no desire to re-invent the wheel. 38 | 39 | _Q) If we’re reusing tech, how low a level do we start the API at? Should it be just a layer on, say, common crypto?_ 40 | * The starting point is probably just to build a common “translation layer” in Swift, and then see if we want to build abstraction layers on top of that. 41 | * It’s easier to build up than it is to build down. 42 | 43 | _Q) Which tech would we use?_ 44 | * If we want to be consistent on iOS clients and servers, then we need to use CommonCrypto/SecureTransport/Keychain at least there, and it would therefore make sense to on macOS as well. 45 | * On the other platforms, OpenSSL or LibreSSL probably makes sense. 46 | The key is making the Swift API consistent, so applications and packages that use the API can be ported. 47 | * There may be some issues around IO handling, certificate handling and config though. 48 | * There’s already an attempt to do this kind of thing in BlueSSLService, so a walk through of that might be informative of potential issues/roadblocks/dragons as we build the new approach. 49 | 50 | ### Next Steps/Actions: 51 | * Everyone to review minutes 52 | * Chris to post minutes to work group Git Repo and send a link to the mailing list 53 | * Next meeting in 2ish weeks - Gelareh to walk through BlueSSLService and issues/pitfalls found during its development. -------------------------------------------------------------------------------- /meetings/security/2016-12-14/minutes.md: -------------------------------------------------------------------------------- 1 | # Swift Server APIs: Security stream meeting 1 2 | 3 | ### Initial Agenda: 4 | * Current discussion status roundup 5 | * Review of BlueSSLService, a layer on top of OpenSSL and macOS Secure Transport libraries: BlueSSLService Review 6 | * Next Steps 7 | 8 | ### Attendees: 9 | * Chris Bailey 10 | * David Sperling 11 | * Gelareh Taban 12 | * Alfredo Delli Bovi 13 | * Bill Abt 14 | * Alex Blewitt 15 | 16 | # Minutes: 17 | 18 | _Scope of the Security APIs:_ 19 | * The scope of what's eventually intended is the full set of APIs, spanning across secure transport (SSL/TLS), crypto, and keychain/certificate management, etc 20 | * The aim is also to provide a consistent set of APIs across both clients and servers, although not all APIs may be available in every case 21 | * Which crypto depends on what’s available (and whether there are requirements above/beyond what we get from the macOS and/or OpenSSL/LibreSSL libs). 22 | 23 | _Review of approach taken in BlueSSLService:_ 24 | * BlueSSLService covers the "secure transport" part of the APIs. There's also a BlueCryptor library that covers crypto. 25 | * It provides a service that adds onto an existing socket library conforming to a protocol. The only implementation of that is currently BlueSocket, but it could be easily modified to work with other socket implementations. 26 | * 6 protocol methods need to be implemented in the socket library. 27 | * A method in the SSL service to let you override the connection verification process to allow for specialized connection verification on an application basis. 28 | * The initial implementation of BlueSSLService uses OpenSSL on all platforms (including macOS), but was then modified to use SecureTransport on macOS. 29 | * The APIs are very different between OpenSSL and SecureTransport, and there was some struggle with the SecureTransport documentation. 30 | * OpenSSL provides much more flexibility for configuration. macOS/SecureTransport is limited to using pkcs#12, although there are internal APIs for dealing with other formats (such as PEM) that are not exposed. 31 | * Do we need support for PEM, etc? Probably - it’s much more prevalent in Linux/server use cases. 32 | * This might be because of usability, and only exposing what users need. With the addition of server use cases, this may need to change. 33 | * For Cipher suites, SecureTransport uses the hex IANA value to select cipher suites whereas OpenSSL lets you use text abbreviations (corresponding to the IANA values), as well as AND/OR logic. 34 | * The result is that you get more capabilities on Linux from OpenSSL than you get on macOS from SecureTransport 35 | * Additionally BlueSSLService doesn’t work on iOS because some of the SecureTransport APIs aren’t exposed. 36 | * But that's not a problem if these APIs aren't required there (ie. the user required function is provided by things like URLSession) 37 | 38 | _Use of OpenSSL vs LibreSSL:_ 39 | * OpenSSL is being used as it provides FIPS certification, whereas LibreSSL does not 40 | * There's a number of other forks of OpenSSL, but its not believed that any of the others is FIPS certified. Additionally most of the forks are subsets of the function. 41 | * Reusing OS libs also makes it easier to get FIPS certification as they are already certified on macOS and iOS and there is a certified version of OpenSSL available for Linux. 42 | 43 | _Review of BlueCryptor for Crypto:_ 44 | 45 | 46 | * BlueCryptor attempts to do the same thing for Crypto, using CommonCrypto on iOS and macOS, and OpenSSL on Linux. 47 | * In CommonCrypto, the function that is missing is RSA. Similar to the issue with other file formats in BlueSSLService, RSA is there in the library, but not exposed publicly. In OpenSSL, RSA is available and the API is similar enough to the CommonCrypto API that it could be easily exposed in BlueCryptor as well. 48 | 49 | _Keychain Services:_ 50 | * Nothing has yet been tried for keychain services. Keychain services is great on macOS/iOS, but there is no equivalent in Linux 51 | * Linux just relies on certificates etc being present on the file system 52 | * A lot of Linux servers, particularly Java based ones, use a CMS (Certificate Management System) to manage certificates and keys. This is similar to the services provided by the Keychain API on Apple platforms. 53 | * Further work is required to understand if we need to implement something here, or expect the user to deal with certificate management themselves (on a per-OS basis). 54 | 55 | _Use of BlueSSLService and BlueCryptor as a prototype implementation:_ 56 | * Should we use BlueSSLService and BlueCryptor as a prototype implementation, and use that to work on the API surface? 57 | * This seems like a reasonable approach 58 | 59 | ### Next Steps: 60 | * Discuss the implemented, but not exposed, function in SecureTransport and CommonCrypto with Luke Hiesterman 61 | * Carry out more investigation on the need (if any) for common certificate/keychain management 62 | * Start to build an outline proposal for the Security libraries for use as a Swift Evolution "pitch" 63 | -------------------------------------------------------------------------------- /meetings/security/2017-02-06/minutes.md: -------------------------------------------------------------------------------- 1 | 2 | # Swift Server APIs: Security stream meeting 2 3 | 4 | ## Initial Agenda: 5 | - Current discussion status roundup 6 | - Review of draft pitch: https://github.com/swift-server/security/blob/master/README.md 7 | - The API design 8 | - API differences between platforms (if any) 9 | 10 | If you have items you want to make sure are on the agenda, please add them below: 11 | 12 | ## Attendees: 13 | - Gelareh Taban 14 | - Joannis Orlandos 15 | - Bill Abt 16 | - Dave Sperling 17 | - Logan Wright 18 | - Chris Bailey 19 | - Stevey Brown 20 | 21 | ## Minutes: 22 | 23 | Scope of library: 24 | - MongoKitten also does some of its own MD5 checksum hashing. It should really get this from a standard lib - so the “Server APIs” for security shouldn’t just limit itself to TLS but also crypto functionality. 25 | - The aim isn’t just to do TLS and implement APIs for “server specific” use cases - we need to solve the wider problem of having consistency for all security/crypto across Linux and Darwin platforms. 26 | - *Decision:* Server Security APIs initially to cover TLS and crypto functionality, similar to OpenSSL. 27 | 28 | LibreSSL vs OpenSSL: 29 | - MongoKitten uses LibreSSL (from vapor) and using OpenSSL (elsewhere) can cause symbol conflicts during build. We need to consolidate on a single implementation. 30 | - LibreSSL vs OpenSSL in Vapor: decision was based on following factors: 31 | - Issues where there’s two users of OpenSSL at the same time on Darwin. 32 | - N/A since won’t be using OpenSSL on Darwin 33 | - Easier instructions for compiling the code in 34 | - N/A if link against library 35 | - Some chat/forum discussion that implied that LibreSSL doesn’t have all of the vulnerabilities that exist in OpenSSL. 36 | - LibreSSL APIs seemed a little easier to work with for transport. LibreSSL was also faster (10x?) for crypto 37 | - LibreSSL is a subset of OpenSSL functionality, and one that doesn’t have FIPS compliance. Is this an issue? Probably for long term “enterprise” usage, especially for government work. 38 | - We want to have a layer over OpenSSL and SecureTransport/CommonCrypto, so switching OpenSSL <-> LibreSSL under the same API should be possible. 39 | - *Decision:* Use OpenSSL on Linux 40 | 41 | Dynamic vs static linking of OpenSSL: 42 | - Compiling to vs. linking to the security library. 43 | - Vapor had some problems with determining location of library on different distros of Linux or macOS which can be problematic during run. 44 | - N/A for macOS or unsupported distros. 45 | - *Decision:* 46 | - In the short term, linking on both Linux and Darwin. 47 | - In the longer term, if security library becomes part of the Swift tool chain, we could potentially compile-in on Linux (removing the need for dependencies). 48 | 49 | New requirement: Support blocking and non/blocking I/O 50 | 51 | New requirement: API to be Swifty 52 | - Need to define what a “Swifty” API is!!! Value types vs. Reference types, etc. String handling? 53 | 54 | Missing functionality in underlying library 55 | - What do we do where platforms don’t have equivalent crypto capabilities on all platforms? We shouldn’t provide just the lowest common denominator, we should make it possible to report capabilities. If Darwin platforms are lacking, we should work with Apple to add new cyphers if needed. 56 | - ALPN APIs missing from Secure Transport APIs for TLS 1.3 57 | 58 | Isolation from I/O protocol: 59 | - Streams vs. sockets as input for SSL - being able to abstract the socket away so we’re just giving a stream of bytes would be ideal. 60 | - Similar to SSLEngine which is basically just a “state machine” that handles encrypting / decrypting via passing in buffers. This way it is easy to hook this in for Sockets that are either blocking or non-blocking or either just in processing pipelines that have no notion of sockets at all. 61 | - Example: Netty has an implementation of such an SSLEngine that uses OpenSSL under the hood (via BIO abstraction) and so provide a fast dropping replacement for the JDK implementation. 62 | - https://github.com/netty/netty/blob/4.1/handler/src/main/java/io/netty/handler/ssl/ReferenceCountedOpenSslEngine.java 63 | - https://github.com/netty/netty-tcnative/blob/1.1.33/openssl-dynamic/src/main/java/org/apache/tomcat/jni/SSL.java 64 | - *Decision:* add to requirements 65 | 66 | 67 | -------------------------------------------------------------------------------- /meetings/security/2017-04-21/minutes.md: -------------------------------------------------------------------------------- 1 | # Swift Server APIs: Security Stream Meeting 5 2 | 3 | ## Initial Agenda: 4 | - General discussion 5 | - APIs 6 | - Hosting, committer groups, reviewers 7 | - Testing 8 | - CI 9 | - Naming 10 | - Call for participation :-) 11 | 12 | If you have items you want to make sure are on the agenda, please add them below: 13 | 14 | ## Attendees: 15 | - Gelareh Taban 16 | - Ryan Collins 17 | - Michael Chiu 18 | - Johannes Weiss 19 | - Gregor Milos 20 | - Kevin Sweeney 21 | - Chris Bailey 22 | 23 | # Minutes: 24 | - APIs have been shared with mailing list and feedback received 25 | - Pitch sent to Swift Evolution mailing list: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035139.html 26 | - ACTION: Gelareh to work with Luke for more security reviews of code 27 | - ACTION: Gregor to send email to Norman Maurer and get feedback on API design and how streams can be used with OpenSSL 28 | - Project repo: https://github.com/swift-server/security 29 | - ACTION: Chris Bailey to set up Teams: admin, committer (DONE) 30 | - Testing options: 31 | - Separate test project with TLS + socket 32 | - Or bare bone socket library within Test of the TLS library 33 | - → We will go ahead with the minimal socket library within TLS project whilst the server group’s socket library has not yet been implemented. 34 | - Michael Chiu is providing his socket library https://github.com/michael-yuji/CKit 35 | - Goal is to use Swift CI. TBD: plugins for orgs and build setup etc. 36 | - ACTION: Chris to work with Mishal Shah to figure out how this can be set up 37 | - Short term: Not have CI/CD pipeline. Lots of local testing for reviewers and mergers. 38 | - Naming: TLSService, TLSEngine, TLSTransport, TLSOverlay, TLS? 39 | - Call for Contributor or reviewers 40 | - Send regular updates to mailing list as we start implementing 41 | 42 | 43 | --------------------------------------------------------------------------------