Previously, set_ech_keys would consume the SslEchKeys struct to enforce the requirement that the struct is immutable after initializing it on a SSL_CTX. The problem with this is that it requires applications to needlessly reallocate the SslEchKeys struct if they want to initialize keys on multiple SSL_CTXs, which is a pretty common pattern. To work around this, we introduce a builder (SslEchKeysBuilder) that requires mutable access to add keys to the underlying struct. set_ech_keys takes in a reference to SslEchKeys, which can only be made via consuming the builder. |
||
|---|---|---|
| .github/workflows | ||
| boring | ||
| boring-sys | ||
| hyper-boring | ||
| scripts | ||
| tokio-boring | ||
| .gitignore | ||
| .gitmodules | ||
| .rusty-hook.toml | ||
| Cargo.toml | ||
| README.md | ||
| RELEASE_NOTES | ||
| THIRD_PARTY | ||
| cliff.toml | ||
README.md
boring
BoringSSL bindings for the Rust programming language and TLS adapters for tokio and hyper built on top of it.
Documentation
- Boring API: https://docs.rs/boring
- tokio TLS adapters: https://docs.rs/tokio-boring
- hyper HTTPS connector: https://docs.rs/hyper-boring
- FFI bindings: https://docs.rs/boring-sys
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed under the terms of both the Apache License, Version 2.0 and the MIT license without any additional terms or conditions.
Accolades
The project is based on a fork of rust-openssl.