[swift-evolution] Crypto routines as part of the core library

[Matthew Johnson]

+1 from me also.  

I really want to see the community converge on a set of "official" Swifty libraries / modules for everything that is widely used.  This doesn't necessarily *need* to be stdlib or corelibs but those are all we have at the moment.  

While their design leaves something to be desired in many cases, the "batteries included" approach of Java and .NET is one thing they got right.  I don't know Go, from what I have heard this also has a lot to do with the popularity of Go (among other things of course).

If there is an "official" library maintained by the community it saves us all a bunch of time - time spent either writing out own or evaluating libraries written by others.  It also provides the best guarantee of future maintenance we can hope to have.

Matthew

Sent from my iPad

> On Apr 14, 2016, at 5:26 PM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Travis / Michael,
> 
> +1 on built-in support for Crypto libraries in swift-corelibs.
> 
> 
> 
> On 14 April 2016 at 22:52, Michael Ilseman via swift-evolution
> <swift-evolution at swift.org> wrote:
>> Great! I will watch that thread as it’s something I’m also interested in
>> knowing more about. Thanks for bringing it up!
>> 
>> On Apr 14, 2016, at 2:51 PM, Travis Beech <tbeech at unwiredrevolution.com>
>> wrote:
>> 
>> Thanks Michael for the input. I realized that after your last response I was
>> indeed mixing terms. I will post up on the swift-corelibs-dev list.
>> 
>> Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209)
>> 535-5357
>> Optimizing Operations for Mobile and Distributed Systems
>> 
>> From: <milseman at apple.com> on behalf of Michael Ilseman <milseman at apple.com>
>> Date: Thursday, April 14, 2016 at 2:49 PM
>> To: Travis Beech <tbeech at unwiredrevolution.com>
>> Cc: David Waite <david at alkaline-solutions.com>, "swift-evolution at swift.org"
>> <swift-evolution at swift.org>
>> Subject: Re: [swift-evolution] Crypto routines as part of the core library
>> 
>> 
>> On Apr 14, 2016, at 2:42 PM, Travis Beech <tbeech at unwiredrevolution.com>
>> wrote:
>> 
>> It should be provided by Swift, not some unknown developer out on Github, no
>> matter how good his\her credentials are. I see core libraries as part of the
>> language runtime. If you look at other modern languages such as Java, crypto
>> is there out of the box, you don’t have to do anything extra to get support.
>> No extra jars to download, etc. and that’s how it should be with Swift.
>> 
>> 
>> Ah, I think we have a problem with our definition of terms. When I say
>> “language feature” I’m referring to syntax, semantics, and other compiler
>> enhancements that may be necessary. What you’re describing can be solved
>> entirely in the core libraries without direct language or compiler changes.
>> In the case of Java, there is no *language* support, but there library
>> support in the standard included libraries. That is, there is no special
>> syntax or compiler changes to support this, just bundled Java code. This is
>> in contrast to, e.g. regular expressions in scripting language like perl or
>> ruby, where there is actual syntax and semantics that make using them
>> easier, as opposed to other languages that just have them in libraries.
>> 
>> I think having an official sanctioned, Swift-provided (via the core
>> libraries) crypto library makes sense, but again I’m not familiar with the
>> core libraries. Please also ask on swift-corelibs-dev, as they might know
>> better if there’s already efforts underway.
>> 
>> 
>> Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209)
>> 535-5357
>> Optimizing Operations for Mobile and Distributed Systems
>> 
>> From: <milseman at apple.com> on behalf of Michael Ilseman <milseman at apple.com>
>> Date: Thursday, April 14, 2016 at 2:38 PM
>> To: Travis Beech <tbeech at unwiredrevolution.com>
>> Cc: David Waite <david at alkaline-solutions.com>, "swift-evolution at swift.org"
>> <swift-evolution at swift.org>
>> Subject: Re: [swift-evolution] Crypto routines as part of the core library
>> 
>> 
>> On Apr 14, 2016, at 2:36 PM, Travis Beech <tbeech at unwiredrevolution.com>
>> wrote:
>> 
>> Core libraries would be a great place, I just think this is a huge oversight
>> in the language itself. I don’t think libraries found out on Github should
>> be trusted, I think crypto should be done in an organized effort to ensure
>> that the implementations are proper.
>> 
>> 
>> 
>> That sounds like a contradiction. “Core libraries would be a great place”
>> and “this is a huge oversight in the language itself”. Could you describe
>> what language-level functionality would be needed here that can’t be
>> adequately addressed by the core libraries? Do you know of any major
>> programming language with language level features for crypto support, as
>> opposed to solving it through a library?
>> 
>> Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209)
>> 535-5357
>> Optimizing Operations for Mobile and Distributed Systems
>> 
>> From: <milseman at apple.com> on behalf of Michael Ilseman <milseman at apple.com>
>> Date: Thursday, April 14, 2016 at 2:33 PM
>> To: Travis Beech <tbeech at unwiredrevolution.com>
>> Cc: David Waite <david at alkaline-solutions.com>, "swift-evolution at swift.org"
>> <swift-evolution at swift.org>
>> Subject: Re: [swift-evolution] Crypto routines as part of the core library
>> 
>> Why would it need to be built into the language proper instead of the core
>> libraries? I am not too familiar with the core libraries, but perhaps
>> swift-corelibs-dev is the more appropriate mailing list here?
>> 
>> On Apr 13, 2016, at 7:24 PM, Travis Beech via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> So what would it take to get a standard set of crypto API's built into the
>> language?
>> 
>> Travis Beech  |  Principal Developer  |  Unwired Revolution  |  c: 1 (209)
>> 535-5357
>> Optimizing Operations for Mobile and Distributed Systems
>> 
>> On Apr 13, 2016, at 10:11 AM, David Waite <david at alkaline-solutions.com>
>> wrote:
>> 
>> I don’t know if we need a boost-like parent project in order to start
>> building core code to be brought for inclusion.
>> 
>> I think success will naturally bring such a project structure - people
>> seeking a curated and integrated set of frameworks to get common
>> functionality.
>> 
>> -DW
>> 
>> On Apr 13, 2016, at 12:16 PM, Tino Heth via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> This seems like a great candidate for a library that could be developed in
>> the community and then possibly brought into Corelibs in a future version
>> 
>> true — but sadly, there seems to be either no interest or manpower for a
>> boost-like infrastructure…
>> Like many other fundamental topics, I don't think crypto belongs to the
>> stdlib, but none the less, there should be a standard library for
>> encryption/hashing.
>> _______________________________________________
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution