Improving Crypto on All Platforms

Server Development
39

I want to bring up one more solution to the naming problem here. Arguably Crypto is the right name for the module and I would like to see this being used forward. It would make the migration story easier. I also agree that it is important to retain the possibility to avoid the BoringSSL dependency on Apple platforms. It brings in a lot of binary size and we expect that a lot of our server libraries are used in client side applications as well.

The solution to this that I have in mind is using the currently in review package traits. This would allow us to make the BoringSSL dependency optional on a trait like this

targets: [
    .target(
        name: "Crypto",
        dependencies: [
            .target(
                name: "CCryptoBoringSSL",
                condition: .when(traits: ["BoringSSL"])
            ),
        ]
    )
]

once the BoringSSL trait is enabled by a consumer the additional APIs currently in CryptoExtras would become available from the Crytpo module.

On a slightly related note, we could also add a new trait UnsafeCrypto to the package which could gate some of the algorithms that we are nowadays considered problematic but are still used by legacy systems.

3 Likes