Use swift-crypto #5852
Use swift-crypto #5852
Conversation
| @@ -10,6 +10,7 @@ bazel_dep(name = "bazel_skylib", version = "1.7.1") | |||
| bazel_dep(name = "platforms", version = "0.0.10") | |||
| bazel_dep(name = "rules_apple", version = "3.8.0", repo_name = "build_bazel_rules_apple") | |||
| bazel_dep(name = "rules_swift", version = "2.1.1", repo_name = "build_bazel_rules_swift") | |||
| bazel_dep(name = "rules_cc", version = "0.0.16", repo_name = "build_bazel_rules_cc") | |||
There was a problem hiding this comment.
Not sure whether we need to do anything else to make sure downstream packages handle rules_cc correctly
There was a problem hiding this comment.
No should be fine. IIRC rules_cc was split out of Bazel’s core in 7.0.
|
I’m a bit torn on this one. This is trading a fairly simple dependency for a considerably more complex one from a build system point of view. If SwiftLint was using some of the more security-sensitive crypto APIs it would be one thing but for just using SHA256 and determining when file contents are likely to have changed, the risk tolerance is different there. I’m inclined to stick with the status quo. What do you think @SimplyDanny ? |
Here's an example of your CHANGELOG entry: * Use swift-crypto.
[kabiroberai](https://github.com/kabiroberai)
[#issue_number](https://github.com/realm/SwiftLint/issues/issue_number)note: There are two invisible spaces after the entry's text. Generated by 🚫 Danger |
I was experimenting with this library myself, because it works well with Swift's new cross-compilation capabilities. The library we currently use doesn't build with the Musl C library linked by the SDK and is thus causing compilation issues when building for another platform. But this could be fixed if cross-compilation becomes a thing for SwiftLint, I guess. For now, I agree with @jpsim in that the maintenance effort isn't worth the benefits. Even the already used library provides so many features we don't use except for hashing. Are there any benefits of using Swift Crypto instead that you have in mind, @kabiroberai, which we miss? |
CryptoSwift is useful for the variety of primitives it offers, but for more limited use cases (such as SwiftLint's usage of SHA256) it's generally preferable to use swift-crypto, given that it's backed by the exceptionally well audited BoringSSL rather than rolling its own Swift primitives.
Discussed with @jpsim out of band.