Decoupled crypto backends (the rest) #428
Conversation
# Conflicts: # Cargo.toml # examples/custom_header.rs # examples/validation.rs # src/crypto/ecdsa.rs # src/crypto/rsa.rs # src/jwk.rs
This is following the existing scheme established in hmac & rsa.
They had todos for docstrings, and I realized they're single-use and should probably not be exposed publicly anyway.
sulami
force-pushed
the
decoupled-crypto-backends
branch
from
4664843 to
76b2fe3
Compare
|
Addressed the latest comments, and also inlined |
|
@Keats Just in case you missed it again, I think this should be good for another review now. |
|
The wasm failure seems legit? |
|
Looking at the AWS-LC docs, I don't think it builds/is supported on WASM. I've also recently read this with regards to default features, and I'm thinking maybe we shouldn't have a default backend after all? That way we could also pick a different backend for the WASM build. |
|
Yeah maybe let's not have a default if the default doesn't work with wasm. |
In most situations AWS-LC is the better backend, but it's not available on all platforms, for example WASM. Explicitly asking the user to pick a backend is also more future-proof.
|
Looks like legit failures as well |
|
I don't know if this'll work or not, at least it builds on my machine, but it doesn't pass the WASM tests. Neither does master though, so I'm not sure that counts for much. I'm not terribly familiar with WASM overall, so I wouldn't mind additional pointers & opinions. |
This is fixing a Clippy complaint.
sulami
force-pushed
the
decoupled-crypto-backends
branch
from
6619f3b to
570d732
Compare
sulami
force-pushed
the
decoupled-crypto-backends
branch
from
570d732 to
eca3603
Compare
|
I've addressed @jplatte's feedback, and I've also run a wasm CI run in my fork to shorten the feedback loop a bit here. |
| @@ -80,7 +80,7 @@ jobs: | |||
| run: cargo install wasm-pack | |||
|
|
|||
| - name: Run tests default features | |||
| run: wasm-pack test --node --features rust_crypto | |||
| run: wasm-pack test --node --features rust_crypto,getrandom/js | |||
There was a problem hiding this comment.
There's a related issue: #431
But I don't know enough about wasm to know what to actually do
There was a problem hiding this comment.
I think this PR might actually help with that, given getrandom/js is now only enabled in CI. Users may be able to enable another wasm-compatible getrandom backend after this lands.
|
Any other breaking change we want to add? I know i'm not happy about EncodingKey/DecodingKey in general but I don't have a better idea right now. |
|
Any ideas why the jobs are stuck? |
.github/workflows/ci.yml
Outdated
| backend: [ aws_lc_rs, rust_crypto ] | ||
| include: | ||
| - build: pinned | ||
| os: ubuntu-20.04 |
There was a problem hiding this comment.
I believe ubuntu-20.04 is no longer supported by GHA. Need tp upgrade to 22.04 or 24.04.
Running most of them on the latest version, at the moment 24.04, except for the test run that's pinned to Rust 1.73, which is pinned to 24.04.
|
looks like we need to bump the pinned version in CI as well |
Some dependencies are now on the 2024 edition.
|
All good! I'll probably release a new version based on this PR this week if I don't forget |
This is following up on #410 with the rest of the decoupled implementations, and addressing most of the review comments (I think?).
There are still some todos left for documentation, which I haven't filled in yet.
I've verified that tests & clippy pass with all combinations of features, but a lot of this I only know enough about to be dangerous, so I'd appreciate close looks at the actual implementations to make sure e.g. I've picked the correct library functions in each case.