No mention of *ring* I guess :/
-
-
Oh I see your point. Some of BoringSSL's API is already that way, like the Ed/X25519 stuff. Not sure how far they can push it for the existing APIs, though.
-
I think my current view on mallocs is that they're worth clearing where easy or perf-impacting. Otherwise it probably does not justify maintaining a parallel API on it's own. But if I'm already reworking something, it's on the back of my mind.
-
Also we're not at all suggesting that BoringSSL is some platonic ideal. We need it to support vast amounts of code that grew up with OpenSSL. It's very much shaped to meet those, Google-specific, needs. If you're not Google, the BoringSSL API is unlikely to be best for you.
-
It's actually more about practicalities, especially w.r.t. the FIPS 140 validation in commercial settings. Also, a lot of the work I have done in *ring* is to sketch the structure of a formally verified implementation and it's not clear that Rust (or even C) is ultimately needed.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.