You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@spark.apache.org by "viirya (via GitHub)" <gi...@apache.org> on 2026/09/15 21:38:39 UTC
[PR] [SPARK-59552] Upgrade jsonwebtoken to 10 and select the rust_crypto provider [spark-connect-gateway]
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-59552] Upgrade jsonwebtoken to 10 and select the rust_crypto provider [spark-connect-gateway]
Posted by "viirya (via GitHub)" <gi...@apache.org>.
viirya closed pull request #29: [SPARK-59552] Upgrade jsonwebtoken to 10 and select the rust_crypto provider
URL: https://github.com/apache/spark-connect-gateway/pull/29
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-59552] Upgrade jsonwebtoken to 10 and select the rust_crypto provider [spark-connect-gateway]
Posted by "viirya (via GitHub)" <gi...@apache.org>.
viirya commented on PR #29:
URL: https://github.com/apache/spark-connect-gateway/pull/29#issuecomment-5689222987
Thank you @dongjoon-hyun !
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org