b65e450813
**Note:** _this pull request has a companion pull request in the [`complement-crypto`](https://github.com/matrix-org/complement-crypto/pull/229) repository, which must be merged in conjunction with this one._ _Before merging, this should be tested in conjunction with the Element X iOS client to ensure that TLS v1.3 is working properly._ @stefanceriu has agreed to work on this. ## Overview The primary change in this pull request upgrades the `reqwest` dependency to its latest version, which defaults to using `rustls` with support for `rustls-platform-verifier` instead of `native-tls` (see [`reqwest@0.13.0`](https://github.com/seanmonstar/reqwest/releases/tag/v0.13.0)). The benefit here is that `rustls` supports TLS v1.3 on all platforms, whereas [`native-tls` does not](https://github.com/sfackler/rust-native-tls/pull/278). Additionally, this pull request makes `rustls` the default TLS implementation in all the crates in this repository. This will be particularly helpful with element-hq/element-x-ios#786. ## Changes - `reqwest` bumped to `0.13.1` - The API for adding/replacing certificates has changed a bit, so this required some updating in `HttpSettings::make_client` - `oauth2-reqwest` added in favor of `oauth2/reqwest` - This is required in order to be compatible with `reqwest^0.13` - _**`oauth2-reqwest` is currently in alpha release, so it probably makes sense to let this stabilize a bit.**_ For details, see https://github.com/ramosbugs/oauth2-rs/issues/333#issuecomment-3906712203. - `getrandom` bumped to `0.3.4` - This is required in order to be compatible with `oauth2@5.1.0` - `proptest` bumped to `1.9.0` - This is required in order to be compatible with `getrandom@0.3.4` - Make `rustls` the default TLS implementation ## Questions ### Mirror feature flag names? A number of feature flags have been replaced in the dependencies above. 1. _**`reqwest/rustls-tls` => `reqwest/rustls`**_ - this is simply a name change, but is semantically identical (see [`reqwest@0.13.0`](https://github.com/seanmonstar/reqwest/releases/tag/v0.13.0)). 2. _**`getrandom/js` => `getrandom/wasm_js`**_ - the semantics here have changed slightly, but it seems to just make it easier to enable the `wasm_js` backend (see [`getrandom@0.3.4`](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md#major-change-to-wasm_js-backend)). At any rate, I have updated references to these flags in each of the various `Cargo.toml` files, but have not changed the names of our exposed features to mimic those in the dependencies. Any thoughts or preferences on whether to mirror those names? That would, of course, result in a breaking change. ### Default to using `rustls`? Deprecate `native-tls`? Now that the dependencies have all been bumped, we can use `rustls` on all platforms. Should this be the new default given that `native-tls` will very likely never support TLS v1.3 on Apple devices? And should `native-tls` be deprecated as a result? **UPDATE:** _The consensus here seems to be that we should default to using `rustls`, but that `native-tls` should still be available._ --- Fixes #5800. - [ ] Public API changes documented in changelogs (optional) Signed-off-by: Michael Goldenberg <m@mgoldenberg.net> --------- Signed-off-by: Michael Goldenberg <m@mgoldenberg.net>
Benchmarks for the rust-sdk crypto layer
This directory contains various benchmarks that test critical functionality in the crypto layer in the rust-sdk.
We're using Criterion for the benchmarks, the full documentation for Criterion can be found here.
Running the benchmarks
The benchmark can be run by using the bench command of cargo:
$ cargo bench
This will work from the workspace directory of the rust-sdk.
To lower compile times, you might be interested in using the profiling profile, that's optimized
for a fair tradeoff between compile times and runtime performance:
$ cargo bench --profile profiling
If you want to pass options to the benchmark you'll need to specify the name of the benchmark:
$ cargo bench --bench crypto_bench -- # Your options go here
If you want to run only a specific benchmark, pass the name of the benchmark as an argument:
$ cargo bench --bench crypto_bench "Room key sharing/"
After the benchmarks are done, a HTML report can be found in target/criterion/report/index.html.
Using a baseline for the benchmark
The benchmarks will by default compare the results to the previous run of the benchmark. If you are improving the performance of a specific feature and run the benchmark many times, it may be useful to store a baseline to compare against instead.
The --save-baseline switch can be used to create a baseline for the benchmark.
$ cargo bench --bench crypto_bench -- --save-baseline libolm
After you make your changes you can use the baseline to compare the results like so:
$ cargo bench --bench crypto_bench -- --baseline libolm
Generating Flame Graphs for the benchmarks
The benchmarks support profiling and generating Flame Graphs while they run in profiling mode using pprof.
Profiling usually requires root permissions, to avoid the need for root
permissions you can adjust the value of perf_event_paranoid, e.g. the most
permisive value is -1:
$ echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
To generate flame graphs feature, enable the profiling mode using the
--profile-time command line flag:
$ cargo bench --bench crypto_bench -- --profile-time=5
After the benchmarks are done, a flame graph for each individual benchmark can be
found in target/criterion/<name-of-benchmark>/profile/flamegraph.svg.