Crate features are intended to be additive, whereas only 1-of-N possible
backends can be selected.
Features can also be activated by transitive dependencies, which leads
to a problem of different dependences selecting conflicting backends.
Using `--cfg` instead moves all backend selection control to the
toplevel executable.
This commit switches to the following RUSTFLAGS to enable backends:
- `--cfg curve25519_dalek_backend="fiat"`: uses `fiat-crypto`
- `--cfg curve25519_dalek_backend="simd"`: uses nightly-only SIMD
* Restructure README and CHANGELOG
* Explain semver policy
* Specify feature flags and backends more explicitly
* Remove nightly from the CI bc that didn't belong there
* Add @pinkforest to thankyou list
Co-authored-by: pinkforest <36498018+pinkforest@users.noreply.github.com>
Previously `cargo test --no-default-features` would succeed but with
warnings. This commit fixes all of those warnings and tests
`--no-default-features` in CI to ensure that in perpetuity.
As proposed in #442 this makes `digest` an
optional feature that is not covered by the
SemVer public API stability guarantees.
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
As proposed in #442 this makes `rand_core` an
optional feature that is not covered by the
SemVer public API stability guarantees.
Co-authored-by: Michael Rosenberg <michael@mrosenberg.pub>
As suggested in #453 it is sometimes feasible to
select the backend bits via an override.
This change provides `cfg(curve25519_dalek_bits)`
to override the bits used in serial or fiat target backend.
GitHub Actions runners are not guaranteed to have the necessary CPU
features in order for these tests to work.
Uses a `--target x86_64-unknown-linux-gnu` directive when compiling so
the `target_feature` flags don't apply to build scripts.
* Deprecated `EdwardsPoint::hash_from_bytes` and renamed to
`EdwardsPoint::nonspec_map_to_curve`
* Added KAT test vectors for `RistrettoPoint::from_uniform_bytes`
- Consolidate `test` jobs: this allows reusing intermediate artifacts
between tests which should improve build times, and also make it
easier to test additional features in the future
- Switch to `dtolnay/rust-toolchain` for setting up toolchain
- Bump checkout to `actions/checkout@3`
- Switch to `run` directives for invoking Cargo: it's more
straightforward to just call Cargo than use a DSL from an unmaintained
action, and eliminates the 3rd party dependency
Also bumps these corresponding dependencies which are needed for everything to compile with this update:
* `merlin` v3.0
* `rand` v0.8
* `rand_core` v0.6
* `sha2` v0.10
The `RUSTFLAGS` were getting applied to build scripts, which caused them
to crash with SIGILL.
According to this issue, RUSTFLAGS won't be applied to build scripts
when cross-compiling by passing the `--target` attribute:
https://github.com/rust-lang/cargo/issues/4423
This attempts to work around the problem by explicitly passing:
--target x86_64-unknown-linux-gnu
As proposed in #414, this commit changes the backend selection approach,
introspecting `target_pointer_width` to select `u32_backend` vs
`u64_backend` (or `fiat_u32_backend`/`fiat_u64_backend` if the
`fiat_backend` feature is enabled).
This helps eliminate the use of non-additive features, and also the
rather confusing errors that happen if multiple backends are selected
(i.e. thousands of lines of rustc errors).
The selection logic checks if `target_pointer_width = "64"` and uses the
64-bit backend, or falls back to the 32-bit backend otherwise. This
means the crate will always have a valid backend regardless of the
pointer width, although there may be odd edge cases for exotic platforms
which would optimally use the 64-bit backend but have a non-"64" target
pointer width for whatever reason. We can handle those cases as they
come up.
As proposed in #426 this commit changes to include README.md into
the crate documentation instead of maintaining a carbon copy in
the code.
This helps to keep the documentation in a single place without
duplicating the documentation in multiple places leading to less
errors and out of date documentation.
Did a full formatting pass on the crate. Read the comments in the referenced for
steps to verify that the PR made no semantic changes to the code. Huge credit
goes to @robjtede for this work.