[swift-server-dev] Crypto Library

[Alfredo Delli Bovi]

Thanks for sharing this!
Nice to read about the details of the implementations and the reasons behind the decisions that you and your team took while making BlueSSLService.

—
Cheers,
Alfredo Delli Bovi

> On 13 Dec 2016, at 16:50, Gelareh Taban via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> To prepare for the Security Group meeting tomorrow, we put together a quick write up of our experience when coming up with consistent Swift APIs for TLS support in Kitura.
> 
> https://developer.ibm.com/swift/2016/12/13/securing-kitura-cross-platform-challenges/ <https://developer.ibm.com/swift/2016/12/13/securing-kitura-cross-platform-challenges/>
> 
> Gelareh
> 
> 
> <graycol.gif>Bill Abt via swift-server-dev ---11/12/2016 10:01:00 AM---I absolutely agree. Why re-invent the wheel? Existing libraries that would be chosen are most like
> 
> From: Bill Abt via swift-server-dev <swift-server-dev at swift.org>
> To: Chris Lattner <clattner at apple.com>
> Cc: Swift Server Dev <swift-server-dev at swift.org>
> Date: 11/12/2016 10:01 AM
> Subject: Re: [swift-server-dev] Crypto Library
> Sent by: swift-server-dev-bounces at swift.org
> 
> 
> 
> 
> I absolutely agree.  Why re-invent the wheel?  Existing libraries that would be chosen are most likely “battle tested and proven”.  To redo all that in Swift seems to me to be a waste of valuable time.  There’s a lot more other work that needs to be done to make server side Swift successful and if that means reusing and leveraging existing “C” code, so be it.
> 
> -Bill Abt
> 
> > On Nov 10, 2016, at 3:02 PM, Chris Lattner via swift-server-dev <swift-server-dev at swift.org> wrote:
> > 
> > 
> >> On Nov 8, 2016, at 2:18 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> >> 
> >> 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
> > 
> > Just my personal opinion, but I don’t see why “pure swift” is a goal or even interesting to thing about.  The goal should be provide expressive and natural Swift APIs for server development tasks.  The implementation should not show through that API.
> > 
> > If (and only if) there is some advantage to rewriting C code in Swift (e.g. for performance, memory, correctness, or capability reasons) then it is certainly interesting to talk about that of course.
> > 
> > A relevant comparison is to corelibs-foundation, which uses a significant amount of C code in its implementation.  
> > 
> > -Chris
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
> 
> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161213/fb6b4127/attachment.html>