Ed25519 was disabled for WebAssembly due to some unrelated issues with
getting the X25519 code working in WebAssembly. Temporarily remove the
`agreement` API when targetting WebAssembly to work around those issues
in a way that lets us enabled Ed25519.
Don't package the inputs of the preassembly; just package the outputs.
Clarify how `mk/package.sh` interacts with `.gitignore`.
Eliminate unnecessary conditional logic in preassembly process.
The assembly headers used for Windows targets need to be generated during packaging so
that the assembly can be preassembled for those targets, but the C header isn't used
during packaging.
I agree to license my contributions to each file under the terms given at the top of each file I changed.
Co-authored-by: Marc-André Moreau <marcandre.moreau@gmail.com>
Localize the use of the "is git" check to a single place and use more
descriptive variables for the various effects that this check has.
As a nice side effect, the loosly-typed `warnings_are_errors` parameters
that were threaded through functions are now gone.
targets.
There is no case where we have .S files for -msvc targets, so this
filter doesn't filter anything out. IIRC, this is stale code from when
the situation was different in the past.
This reduces the amount of logic that is specific to "-msvc" targets and
makes the work to support clang and clang-cl for Windows, and to support
AAarch64 Windows, easier to review.
Now "links" in Cargo.toml is the only thing that needs to be manually modified
when the prefix changes.
build.rs enforces that the package name and version are consistent with the
"links" field.
Eliminate the extra Cargo.toml that was used just for this feature. It was
too error-prone to keep it in sync with the real Cargo.toml. Having one
Cargo.toml will allow us to reliably use the `CARGO_MANIFEST_LINKS` value
to keep the symbol prefix in sync with the `links` field in Cargo.toml in
the near future.
Revert the names used in the BoringSSL C/asm code to the names used in
BoringSSL. This substantially reduces the diff between *ring* and
BoringSSL for these files.
Use a variant of BoringSSL's symbol prefixing machinery to semi-
automatically prefix FFI symbols with the `GFp_` prefix. The names aren't
all exactly the same as before, because previously we *replaced* a
symbol's original prefix with the `GFp_` prefix; now we're prepending
`GFp_`. In the future we'll use a different prefix entirely.
This paves the way for using different prefixes for each version so that
multiple versions of *ring* can be linked into an executable at once.
Assume by default that an operating system does not have an ABI compatible
with the PerlAsm sources. Add all the operating systems that we've
explicitly added support for to the allowlist. Avoid trying to build or
use the PerlAsm code for those targets.
On top of this, we can build fallback logic for using Rust (or C)
implementations for those targets that aren't compatible with the
assembly.
Use Fiat Crypto for non-x86_64 platforms, like BoringSSL. Continue
using the nistz256 code on Windows, differently from BoringSSL.
Make *ring* more consistent with BoringSSL.
The newest Rust Nightly is getting stricter about `forbid(warnings)`
which breaks the build.
Use "deny" instead of "forbid". And only deny when running Clippy in
CI/CD, so that when hacking on *ring* we don't have to deal with
warnings right away; we now only have to deal with them when we're ready
to submit a change to be merged.
Avoid requiring a sysroot for *-linux-musl targets when using Clang.
Add one AAarch64 and one 32-bit ARM MUSL target to GitHub Actions.
Use Rust 1.48's `-Clink-self-contained=yes` in CI for musl targets.
Support the non-default variants of the *-musl targets.
Change the static CPU feature detection logic to assume all aarch64-apple-* targets
have the same capabilities as far as the features we use are concerned.
Use the "ios64" PerlAsm flavour for aarch64-apple-darwin, like OpenSSL upstream does.
Add (build-only) cross-compilation jobs to GitHub Actions.
Previously the OpenSSL implementation was being used. Switch to the BoringSSL
version.
Switching to the BoringSSL implementation will make it easier to refactor the CPU feature
detection, which is important for upcoming ports.
This switch will also implicitly add support for BTI and pointer authentication for
Poly1305.
This is based on BoringSSL 63d06626d3a104868eee622e8e56d9f2dd643366.
