[
https://issues.apache.org/jira/browse/SPARK-60115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
L. C. Hsieh reassigned SPARK-60115:
-----------------------------------
Assignee: L. C. Hsieh
> Pin the transitive h2 dependency to 0.4.16 to pick up RUSTSEC-2026-0258
> -----------------------------------------------------------------------
>
> Key: SPARK-60115
> URL: https://issues.apache.org/jira/browse/SPARK-60115
> Project: Spark
> Issue Type: Sub-task
> Components: Connect
> Affects Versions: connect-gateway-0.1.0
> Reporter: L. C. Hsieh
> Assignee: L. C. Hsieh
> Priority: Major
> Labels: pull-request-available
>
> `cargo audit` against the current main (131c830) reports three advisories.
> This
> addresses the one that is both server-side and has a fix available:
> RUSTSEC-2026-0258 -- h2 unbounded empty DATA frames
> https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
> affected: h2 0.4.15, patched: >= 0.4.16
> Why this one matters here: `h2` reaches the gateway through
> `hyper` -> `tonic` 0.14.6, and the tonic server is the gateway's own
> client-facing listener on :15003. A peer that can open a connection and send
> unbounded empty DATA frames is the threat model of an internet- or
> cluster-facing gRPC proxy, not a hypothetical.
> `h2` is not a direct dependency -- it appears nowhere in `Cargo.toml` -- so
> this
> is a lockfile-only change:
> cargo update -p h2 --precise 0.4.16
> Only the `h2` entry moves; the other 89 resolved dependencies are
> unchanged, and
> no `Cargo.toml` edit is needed or made.
> ### Scope: what this does not fix
> The other two advisories are deliberately left out of this change.
> RUSTSEC-2026-0285 -- rustls 0.23.43, TLS 1.3 handshake messages
> incorrectly
> accepted across encryption level boundaries. Patched in 0.23.45, already
> proposed by dependabot in #47, so it belongs there rather than here. Worth
> noting the gateway's exposure is limited: it does not terminate TLS (no
> `ServerConfig` / `TlsAcceptor` / `ServerTlsConfig` anywhere under
> `crates/`,
> and :15003 is plaintext), and pulls `rustls` only on client paths --
> `kube-client` for the K8s API, `reqwest` for OIDC JWKS, and
> `opentelemetry-otlp`'s `tls-ring`.
> RUSTSEC-2023-0071 -- rsa 0.9.10, Marvin Attack timing sidechannel. No
> patched
> version exists, so there is nothing to bump to. It arrives via
> `jsonwebtoken`'s RSA backend under the `rust_crypto` provider selected in
> SPARK-59552, and needs a decision (accept the risk, or change backend)
> rather
> than a version bump. Possibly worth resolving alongside #39.
> ### A limitation of this fix
> A `--precise` pin on a transitive dependency is not durable: the next
> `cargo update`, or a dependabot bump of `hyper` or `tonic`, can re-resolve
> `h2`
> and silently drop back below 0.4.16.
> The durable fix is running `cargo audit` in CI, which is not wired up today
> --
> all three advisories above reached `main` unnoticed and were found only by
> running it by hand. That is worth its own change.
> ### How was this patch tested?
> Resolution verified before committing:
> $ cargo update -p h2 --precise 0.4.16 --dry-run
> Updating h2 v0.4.15 -> v0.4.16
> Full workspace on the pinned 1.99.0 toolchain: `cargo clippy --workspace
> --all-targets -- -D warnings` clean, `cargo fmt --all --check` clean, and
> `cargo test --workspace` at 204 passed / 0 failed, matching the baseline on
> main. `cargo audit` then reports RUSTSEC-2026-0258 resolved, with the rustls
> and rsa advisories remaining as described above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
