viirya opened a new pull request, #29:
URL: https://github.com/apache/spark-connect-gateway/pull/29
### What changes were proposed in this pull request?
Move `jsonwebtoken` from 9 to 10 and select the `rust_crypto` backend
explicitly:
```toml
jsonwebtoken = { version = "10", default-features = false,
features = ["use_pem", "rust_crypto"] }
```
`Cargo.toml` and `Cargo.lock` only; no source changes.
This supersedes #6, which is closed.
### Why are the changes needed?
Version 10 makes the crypto backend pluggable and refuses to guess one. What
makes this more than a version bump is that **it fails at runtime, not at
compile
time** — `jsonwebtoken = "10"` on its own builds cleanly, so the gateway
would
start normally and panic on the first JWT it verified:
```
Could not automatically determine the process-level CryptoProvider from
jsonwebtoken crate features. Call CryptoProvider::install_default() before
this
point to select a provider manually, or make sure exactly one of the
'rust_crypto' and 'aws_lc_rs' features is enabled.
```
The 14 test failures dependabot reported on #6 were a symptom of this rather
than
the problem itself.
**Why `rust_crypto`.** It is the pure-Rust provider, consistent with this
repo's
existing choices (`reqwest` with `rustls-tls`, `opentelemetry-otlp` with
`tls-ring`), and it adds no C toolchain dependency — which matters for the
distroless runtime image. The alternative, `aws_lc_rs`, is the FIPS-oriented
route
but brings a C dependency.
**Why `use_pem` is listed explicitly.** It is a *default* feature, so
`default-features = false` with only a provider fails to compile:
`EncodingKey::from_rsa_pem`, used by both the JWT and OIDC verifiers, lives
behind
it. This is an easy trap for anyone revisiting these features later.
### Does this PR introduce _any_ user-facing change?
No. The set of accepted JWT algorithms, the configuration surface, and the
rejection behaviour are all unchanged — see the algorithm round-trip check
below.
### How was this patch tested?
**Every algorithm the gateway's config accepts was checked to sign *and*
verify
under this provider**, not merely to compile. `rust_crypto` listing `p256`
and
`p384` among its features does not by itself prove `ES384` works, and a
provider
missing one algorithm would fail only for the users who had configured it —
invisible to a build and to the unit tests. Real keys generated with
`openssl`,
full round-trip per algorithm:
```
HS256 OK HS384 OK HS512 OK
RS256 OK RS384 OK RS512 OK
PS256 OK PS384 OK PS512 OK
ES256 OK ES384 OK
```
That is all 11 algorithms accepted by `crates/config`.
**No new C dependency**, which is the main reason for choosing this
provider, so
it is worth showing rather than asserting. `jsonwebtoken`'s dependencies are
pure
Rust (`rsa`, `p256`, `p384`, `sha2`, `hmac`, `ed25519-dalek`). `ring` does
appear
in the tree, but `cargo tree -i ring` shows it arriving via `rustls` /
`rustls-webpki`, and it is already present on `main` — unchanged by this
patch.
**The standard quartet:**
| check | result |
|---|---|
| `cargo test --workspace` | 204 passed, 0 failed, 10 ignored — same as the
baseline on `main` |
| `cargo clippy --workspace --all-targets -- -D warnings` | clean |
| `cargo fmt --all --check` | clean |
| `cargo build --workspace` | clean |
The 17 `jwt::` and `oidc::` tests all pass, which includes the 14 that #6
reported
as failing.
One note for review: the `Cargo.lock` diff is large (269 lines) compared
with a
typical bump. That is expected — selecting a provider replaces the crypto
implementation stack rather than moving a single crate.
### Was this patch authored or co-authored using generative AI tooling?
Yes, co-authored with Claude Code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
