This is now achieved by a downstream program not referencing any
TLS1.2 cipher suites/SupportedProtocolVersions, and the linker should
remove `rustls::version::TLS12` and everything hanging off it (which
includes the bottom half of the TLS1.2 handshake) via --gc-sections.
eg. we don't publish ed25519 benchmarks at the minute, so running
them is a waste of effort.
This only applies to TLS1.3 tests, as TLS1.2 implies the auth key
type already.
This means bench can be built for several providers at once,
which then requires (eg) `--provider aws-lc-rs` to be specified.
If there is one provider specified by crate features, this is used
implicitly.
It is no longer possible for rustls-post-quantum and rustls/fips
to co-exist. Bleed that fact into bogo's crate features.
admin/all-workspace-members is a helper to assist running a
command many times for each workspace member, while avoiding
unification.
Hoist clippy calls into a script for use from CI
`from_crate_features()` and `get_default_or_install_from_crate_features()`
became uncovered since 3249a5b39 due to unwanted workspace feature unification.
This is not straightforward because:
- the tests want the FIPS selection to be at runtime, so we
reconstruct the non-FIPS CryptoProvider and use that unless
the `-fips-202205` is passed to the shim.
- BoringSSL's FIPS evaluation is (presumably) older than aws-lc-rs,
and doesn't include ED25519 (ref. FIPS 186-5) or P521.
However, this does provider test coverage that:
- X25519 is not usable
- chacha20-poly1305 is not usable
As an initial starting point, test that the aws-lc-rs HPKE suites from
the main rustls crate and the hpke-rs HPKE suites from the
provider-example crate can interoperate.
This process is slower (~30s) so having the tests in a separate crate is
helpful. It also allows us to take heavier deps (like the
provider-example crate, hpke-rs and rust crypto).
This allows the new, nightly-only, `--branch` argument to
get everywhere it needs to. That enables branch coverage
tracking.
Example use:
$ ./admin/coverage --branch --html --open
To allow for easy running and simplification of benchmarking, add cargo
build to the bench measure.
Also add .PHONY for recipes with no output that are always expected to
run.
* Describe why crypto providers exist, how they are chosen
* Enumerate the built-in providers and associated feature flags
* Link to third-party providers we're aware of
* Add some documentation about implementing a custom provider
The `admin/format-bench` script has bitrot so that it no longer
functions with the current output produced by the benchmark tooling.
It's not clear that this tool is still needed, so rather than fix it or
port it to Rust, we choose to remove it outright.
If it turns out there is a need for formatting benchmarking output we
should consider building that into the benchmark tool itself to avoid
needing to deal with a Python tool-chain and associated versioning
challenges.
Prior to this commit the admin `bench-range`, `capture-certdata` and
`format-bench` Python helpers used a hardcoded path to Python3 in their
shebang. This commit updates each to use `/usr/bin/env` to find
`python3` in the `$PATH`.
These helpers also used Python2 style `print` statements instead of the
Python3 style `print` function. This commit adds the required braces to
fix Python3 usage.
Prior to this commit some helper scripts used hardcoded paths to
`/bin/sh` and `/bin/bash` in script shebangs. This will error on systems
that don't place `bash` in `/bin/` (e.g. NixOS).
This commit updates the scripts to use `/usr/bin/env` to find `bash`
based on the user's `$PATH`. This has better portability and allows the
scripts to run without err (or specifying an interpreter explicitly) on
systems with atypical `bash` installs.
Dirkjan Ochtman