Planning ahead for when WASI is to be supported, require the user to opt into
using web APIs for thw wasm32-unknown-unknown target with a new feature, since
wasm32-unknown-unknown could be used for either web or non-web environments.
Don't bother updating the tests to use this new flag, since the tests aren't
part of the "public API" of *ring*. When we add support for other WebAssembly
environments (e.g. WASI) we'll update the tests then.
This is a step towards removing the heap-allocated and usually-unnecessary
`public_key: RsaSubjectPublicKey` field. The new API allows the caller to
better control how it stores/allocates the component values. This also removes
a couple of infallible `unwrap()`s.
This is a step towards removing `io::Positive` from the public API.
This is a breaking API change.
Alexander Ovchinnikov (@Alovchin91) wrote:
> [C]ould you please also upgrade cc to 1.0.69? This version contains fixes to
> find MSVC tools on Windows ARM.
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>
Take a step towards having RSA keys support encryption/decryption
in addition to signing/verification.
No functional changes are intended.
Some documentation was moved around.
0.17.0-alpha.9 was released off the b/0.17.0-alpha.9 branch. Similarly for
0.17.0-alpha.10 on the b/0.17.0-alpha.10 branch.
Having the version number on the main branch say "0.17.0-alpha.9" or any
version number like that is confusing and misleading. We have to have a
version number, so use one that's clearer while we work on finishing
0.17.0.
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.
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.
Ensure we're always passing in u32-aligned values to `GFp_ChaCha20_ctr32`.
Get rid of the attempt to abstract away the difference between ChaCha20
and AES-CTR w.r.t. counters and IVs. The abstraction wasn't actually used
by any shared code. The AES-CTR (GCM) code does endian conversion in the
assembly so endian conversion cannot easily be deferred to later. For
ChaCha20, it makes more sense to do endian conversion at the time of
`Counter`/`Iv` construction. Despite the slight duplication of logic in
having two `Counter` types and two `Iv` types, this is actually a net
reduction of code. If we ever have a third implementation of these types
we can apply the Rule of Three to factor out the commonality.
Clarify that, on ARM/Aarch64, runtime feature detection is done only for Linux (including
Android) and Fuchsia. Reduce some of the duplication between Linux and Fuchsia; probably we should
do more later.
