Open below opened 7 years ago
krzyzanowskim
commented
7 years ago I'm not going to discuss what should be used, I just point that CryptoSwift has a very wide range of supported Swift versions you can use and skip most of the problems mentioned above.
https://github.com/krzyzanowskim/CryptoSwift#swift-versions-support
below
commented
7 years ago Thank you! I assumed that, given CryptoSwift is a very popular project, Swift 4 support can't be far. This is a research project, and especially sparked my interest when I found out that it is not trivial, and none of the existing solutions (apart from using CryptoSwift) seem to be really clean
Primary Goal
Replace the CryptoSwift dependency in JWT with CommonCrypto
Motivation
When I started to research SFAuthenticationSession, CryptoSwift was apparently not ready for Swift 4 (at least I think that is what triggered me initially). During research, I realised all JWT needs is to calculate a hash, a simple enough task. I like to keep dependencies to an absolute minimum, and also — especially for security — I prefer Apple's platform solution for a number of reasons. So, rather than trying to find a version of CryptoSwift for Swift 4, or fixing it myself, I wanted to calculate the hash using CommonCrypto
The Problem
Importing CommonCrypto into a Swift Framework is not trivial (For Apps, all you have to do is create a bridging header) (Side goal: I would be interested in the deeper reason for this)
Possible Solutions
IBM CommonCrypto Module Map
IBM has a CommonCrypto Module Map. The Problem is that this only works when using the Swift Package Manager
Custom Module Maps
Some are using custom CommonCrypto Module Maps. The Problem is that this solution uses hardcoded Xcode paths, which I consider plain ugly, especially given that Xcode should be self-contained and not location dependent.
Dynamic Module Maps
Again IBM, for their BlueCryptor project is creating dynamic module maps at runtime, always using the correct Xcode location. Here, the Problem is that Run Script build phases are not honored by the current implementation of CocoaPods. And I would like to use CocoaPods to use JWT. I could use the prepare_command, but that does not know what the build architecture will be.
My Question: Where to go from here?
From here, I see various possible routes:
A slim Objective-C wrapper
I could use or create a slim Objective-C wrapper, and add that as a dependency. As my goal was to remove dependencies, this seems contradictory
Use a new version of CocoaPods
In Version 1.4, a new feature is planned that will Add Podfile DSL for 'run script'. I am not sure if that works, also I would like to stick with a stable version of CocoaPods
Lose CocoaPods support
I could go to Swift PM or Carthage instead of CocoaPods. I would like to avoid this.
Coding, Rated R for Violence
Code is simply some instructions lying around, and when you know what you are doing, you can just pick 'em up: This knee deep in blood solution is close to my heart: Rip the dylib open, tear out it's guts and arrange them in pretty shapes. (Remember I am an old Lisp developer: "Lisp is a shiv which comes in many forms. Anyone who uses this is probably crazy and dangerous") However, I realise this is a working, but messy and unstable solution.
Your Input is appreciated
Thanks a lot!