L. C. Hsieh created SPARK-60115:
-----------------------------------
Summary: 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
`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]
