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

Thu Apr 14 17:26:32 CDT 2016

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
>