Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Which is why, they're vendoring a copy of BoringSSL. The readme on their git repo[1] clearly states this.

[1]: https://github.com/apple/swift-crypto



That allows them to avoid the problem, but why introduce the problem in the first place? Why not use something that is intended to be used as a crypto library?


They had an existing API to comply with[1]. NaCl's API doesn't cover everything they need. Their choices were down to 1. Use OpenSSL (or a fork of it, which BoringSSL is) 2. Roll their own crypto. They chose #1 on all other platforms and stayed with #2 on the platforms they control (I might be mistaken here, perhaps they wrap some OpenSSL derivative on their own platforms too). And that in my opinion is a reasonable choice, given the constraints.

[1]: https://developer.apple.com/documentation/cryptokit




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: