867f2b3b99
Internal users often have two builds for `boring`, one using a precompiled build of boringSSL and another built from source with patches applied. However the features that enable these builds are mutually exclusive. For example, the `"pq-experimental"` feature is required to build the source with all of the necessary codepoints for PQ key exchange, but if this feature is enabled and a precompiled boringSSL is provided, then the build will fail. This means users will have to also control their builds with mutually exclusive features. An alternative is to *ignore* features that enable patches whenever a precompiled boringSSL is provided. This is a little different from the "assume patched" environment variable, which applies whenever we're building from source. |
||
|---|---|---|
| .. | ||
| build | ||
| cmake | ||
| deps | ||
| patches | ||
| src | ||
| Cargo.toml | ||
| LICENSE-MIT | ||
| README.md | ||
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.