add Swift Package Manager support with xcframework

[julepka]

Introducing Swift Package Manager support based on xcframework.

Named the package "cl-openssl" to avoid collisions with other possible "openssl" packages. The package points to the xcframework binary that is added to the release assets.

For each new release we'll need to:

• attach the xcframeworks binary to each release as an asset
• update the version number in Package.swift
• commit the change -> create release (so, the release reference the corresponding commit)

Before merging, I need to clarify the versioning, so the path to the binary contains a future release (future version). So, the new release references the commit with the URL pointing to it.

[vixentael]

I need to clarify the versioning

We learnt that SPM likes only semver tags, so v1.1.10802 is not an option anymore, we should use 1.1.10802 (without v).

[vixentael]

extra zero here.

current version is v1.1.10802, next version should be (semver) 1.1.10803

[julepka]

Ok, so the link will be https://github.com/cossacklabs/openssl-apple/releases/download/1.1.10803/openssl-static-xcframework.zip

[ilammy]

By the way, while we're here, maybe bump OpenSSL to 1.1.1j – to be released as 1.1.10901?

[julepka]

@ilammy good point, will do

[julepka]

@ilammy, after discussion with @vixentael we think that it will be better to release the SPM update and then release the updated OpenSSL as two separate releases. So, the users have a workable version of SPM if the new OpenSSL version breaks something.

[ilammy]

We learnt that SPM likes only semver tags, so v1.1.10802 is not an option anymore, we should use 1.1.10802 (without v).

[Expletive] lazy fruit fascists.

[ilammy]

Okay... So for release you need to build a binary, tag a release, attach the binary to GitHub release, and then SPM will download this binary and use it. Overall, this is similar to how existing Carthage and CocoaPods work for CLOpenSSL right now.

SHA-1 checksum in Package.swift gives extra confidence in that the intended binary has been published by us, and that the intended binary has been downloaded by the users. CocoaPods has something similar too.

The packages are versioned by tags. Publishing a tag will publish a release. There is a small gap while the binary is being uploaded, but that should not be a major problem in practice. Carthage is similar in this regard.

The overall setup looks sane to me. While I guess that SPM could be coerced into building OpenSSL on the user's machine – provided that the compilers are dependencies are there – I believe that the userbase is more concerned about things working over the source code purity. And speaking from maintainer's perspective, binary releases are more robust.

Some questions:

• SPM is going to provide only statically-linked builds of OpenSSL, under the cl-openssl name. What would be necessary to provide a dynamically-linked version in the future? Would it be possible to provide both within this repo?

  I know that for now we probably won't need it, but it's good to know how much we are locking ourselves into this name and repo, and the contents.

Some suggestions:

• It would be nice to update RELEASING.md with the steps necessary for SPM maintenance.

[julepka]

@ilammy

• SPM is going to provide only statically-linked builds of OpenSSL, under the cl-openssl name. What would be necessary to provide a dynamically-linked version in the future? Would it be possible to provide both within this repo?
  I know that for now we probably won't need it, but it's good to know how much we are locking ourselves into this name and repo, and the contents.

There several options for linking type. When you do not specify the linking type, then Xcode SPM will do it by itself. It usually ends up linking statically. Devs reported that it links dynamically when there were several packages using the same library (to avoid naming collisions). Apple recommends letting Xcode and SPM decide if it should be linked statically or dynamically: https://developer.apple.com/documentation/swift_packages/product/2878196-library?changes=_6_5 Also, I've seen devs reporting issues when forcing the library to link this or that particular way.

Of course, we will see if the recommended approach works for us :) Hopefully, it is workable.

By the way, I've used an xcframework with a static library. There is no particular reason for that. I wonder if using the dynamic library is a better thing to do... will we notice the difference at all...

• It would be nice to update RELEASING.md with the steps necessary for SPM maintenance.

Sure, will do

[julepka]

Status update: working on an issue reported for OpenSSL -> Themis -> Another library pipeline. This PR will not be merge until we resolve the issue.

[julepka]

Updated instructions for the release process.
Updated Package.swift file
Version in Makefile will be updated when merged, during release.

[ilammy]

I guess this should be

https://github.com/cossacklabs/openssl-apple/releases/tag/1.1.10701

for consistency with instructions in item 5.

[ilammy]

Instead of just throwing a URL, I'd actually put here a snippet of Package.swift:

Update [`Package.swift`](Package.swift) file with the new URL of the binary framework and its checksum:

```swift
.binaryTarget(name: "openssl",
              // update version in URL path
              url:"https://github.com/cossacklabs/openssl-apple/releases/download/1.1.10701/openssl-static-xcframework.zip",
              // Run from package directory:
              // swift package compute-checksum output/openssl-static-xcframework.zip
              checksum: "77b9a36297a2cade7bb6db5282570740a2af7b1e5083f126f46ca2671b14d73e"),
]
```