Vapor 4 and Swift Crypto 2

Swift Crypto 2.0.0 was recently released introducing several new APIs. It's likely that much of the ecosystem will either move over to using it or offering an expanded version range to allow consumers to use both. We'd like to use it with JWTKit to remove yet more BoringSSL code and hopefully at some point remove it all.

However, due to reasons, Vapor 4 is in the frustrating position of exporting Swift Crypto, technically making it part of Vapor's public interface. This will definitely be fixed in Vapor 5, but it means for now, if we were to expand the version range of Crypto that Vapor uses, this would technically be a breaking change.

The core team have decided that a new major version release just for Crypto would be too disruptive for the Vapor community (including all the packages that build on top of Vapor and all the tutorials and books etc that would need changing). We have some upcoming announcements for Vapor 5, but want to make the disruption as infrequent as possible, so a major release is not on the cards.

That leaves us with 2 options:

  • Ignore Swift Crypto 2 - if we follow SemVer strictly then this is really the only option but it would mean that anyone wanting to use Vapor and Swift Crypto would be out of luck. The core team are aware that Vapor was one of the primary things holding back SwiftNIO 2 and the rest of the ecosystem so we are mindful of being in that position again, although Swift Crypto isn't quite as impactful as NIO.
  • Bend the rules a little and bump the version of Swift Crypto depended on, either explicitly or using a 1.0.0 < 3.0.0 range and release it under a minor version update.

The core team have a strong preference to option 2. We believe that anyone switching on the CryptoKitError is probably explicitly depending on Crypto and this change is unlikely to cause any issues for the large majority of people. This also enables us to use Swift Crypto 2 and remove our reliance on C code and potentially remove a copy of BoringSSL in everyone's build chain. We think the benefits far outweigh the downsides but would like to hear from the community first before making a decision. Let us know what you think!

The Vapor Core Team

13 Likes

I’ve expressed this on Discord, but I’m strongly (selfishly) in favour of option 2. It’s technically a breaking change, but the alternative is a potentially very long wait for projects that need access to APIs released with Crypto 2.

1 Like

Option 2 sounds very undisruptive :+1:

Can you summarize or just give an example of the possible breaking changes?

There was a new case added to the CryptoKitError enum

I am also in favor of a minor release with the small breaking change to bring the ecosystem along to Crypto 2.

I’m in favor of option 2 :+1:

My vote goes for option 2.

I’m for option 2

Option 2 is fine by me.

Happy with option 2 as long as it won’t break JwtKit.

Happy with the 2nd option :blush:

The general consensus was option 2 so that's been released in 4.49.0

1 Like

Fantastic! Thanks for managing this decision, Tim Vapor :star_struck: