Swiftpack.co - Swift Packages by aidantwoods

The markdown parsing is broken/disabled for release notes. Sorry about that, I'm chasing the source of a crash that's been bringing this website down for the last couple of days. ## What's Changed * Update minimum dep to iOS v10 by @frederikbosch in https://github.com/aidantwoods/swift-paseto/pull/17 * Allow public init from P384 PublicKey by @frederikbosch in https://github.com/aidantwoods/swift-paseto/pull/18 * Work around a backwards compatibility issue in CryptoKit on macOS 13 (et. al) which prevented importing P384 public keys ## New Contributors * @frederikbosch made their first contribution in https://github.com/aidantwoods/swift-paseto/pull/17 **Full Changelog**: https://github.com/aidantwoods/swift-paseto/compare/1.1.0...1.2.0 ## Summary Support added for Version 3 Public Paseto tokens (on supportable platforms). ## What's Changed * Update test vectors by @aidantwoods in https://github.com/aidantwoods/swift-paseto/pull/15 * Version3 public by @aidantwoods in https://github.com/aidantwoods/swift-paseto/pull/14 **Full Changelog**: https://github.com/aidantwoods/swift-paseto/compare/1.0.0...1.1.0 Version 1 stable release. ## Updates * Added v3.local, v4.public, v4.local support * Added support for dealing with nested JSON structures * Added common validator support No changes to the underlying crypto in v1/v2. Should now build on more recent releases of Xcode: circular type definition removed. There is lots of internal changes – mostly this should result in changes like writing `Message<Encrypted<Version2>>` as `Message<Version2.Local>` and `SymmetricKey<Version2>` as `Version2.SymmetricKey`. To see examples of migration, it may be useful to review [this diff](https://github.com/aidantwoods/swift-paseto/commit/56b5155d429b112cd5eb0aa9499a40cd306caaab), and perhaps the PR https://github.com/aidantwoods/swift-paseto/pull/2 also if there is interest into why these changes have occurred. It's also no longer possible to try to use the "Public" purpose API in version 1 (previously this would throw exceptions or invoke a fatal error since this is not supported – it now just doesn't exist). We now no longer need to create "diverse" types by projecting a type argument to an enum state and alternating behaviour accordingly – instead where different types are required we have used associated types. This should be stable enough to start working with. I don't plan on changing the public API *too drastically*, but we'll see... We can't really have a stable release until the specification hits `v1.0.0` anyway 😉 This should be stable enough to start working with. I don't plan on changing the public API *too drastically*, but we'll see... We can't really have a stable release until the specification hits `v1.0.0` anyway 😉