SwiftLint
SwiftLint copied to clipboard
realm
Use swift-crypto
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.
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 ?
| 2 Warnings | |
|---|---|
| :warning: | If this is a user-facing change, please include a CHANGELOG entry to credit yourself! You can find it at CHANGELOG.md. |
| :warning: | This PR may need tests. |
| 17 Messages | |
|---|---|
| :book: | Linting Aerial with this PR took 0.98s vs 0.93s on main (5% slower) |
| :book: | Linting Alamofire with this PR took 1.26s vs 1.27s on main (0% faster) |
| :book: | Linting Brave with this PR took 7.23s vs 7.25s on main (0% faster) |
| :book: | Linting DuckDuckGo with this PR took 5.09s vs 5.13s on main (0% faster) |
| :book: | Linting Firefox with this PR took 10.69s vs 10.7s on main (0% faster) |
| :book: | Linting Kickstarter with this PR took 9.91s vs 9.93s on main (0% faster) |
| :book: | Linting Moya with this PR took 0.54s vs 0.53s on main (1% slower) |
| :book: | Linting NetNewsWire with this PR took 2.88s vs 2.9s on main (0% faster) |
| :book: | Linting Nimble with this PR took 0.79s vs 0.78s on main (1% slower) |
| :book: | Linting PocketCasts with this PR took 8.48s vs 8.65s on main (1% faster) |
| :book: | Linting Quick with this PR took 0.44s vs 0.44s on main (0% slower) |
| :book: | Linting Realm with this PR took 4.51s vs 4.54s on main (0% faster) |
| :book: | Linting Sourcery with this PR took 2.31s vs 2.32s on main (0% faster) |
| :book: | Linting Swift with this PR took 4.55s vs 4.58s on main (0% faster) |
| :book: | Linting VLC with this PR took 1.25s vs 1.26s on main (0% faster) |
| :book: | Linting Wire with this PR took 18.0s vs 18.11s on main (0% faster) |
| :book: | Linting WordPress with this PR took 11.42s vs 11.57s on main (1% faster) |
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 :no_entry_sign: Danger
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 ?
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?
