The intended effect was to redirect people reading about *ring* on
crates.io to the GitHub-hosted README.md. However, the unintended effect
was that docs.rs is broken for the 0.17.0 release.
`winapi` is in maintenance mode and the new blessed way to access Windows APIs are the `windows`
and `windows-sys` crates. I don't think any types of `winapi` were exposed in the public API so
I used `windows-sys` since it has much faster compile times.
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.
