Issue 7945 - Regenerate Rust lockfile to resolve RUSTSEC-2026-0258

[CJIA-cmd]

Issue

• My PR fully resolves the following issue:
  • Resolves Update h2 to resolve RUSTSEC-2026-0258 #7945

Change

Regenerates rust/Cargo.lock using:

cargo generate-lockfile

This follows the review feedback on the previous PR to avoid manually editing Cargo.lock.

Before regeneration, the branch was reset to the current canonical develop state and the working tree was clean. No part of the generated lockfile was manually edited afterwards.

The regenerated lockfile updates:

h2 0.4.15 -> 0.4.18

which resolves RUSTSEC-2026-0258.

Because cargo generate-lockfile resolves all compatible versions from the current manifests, the resulting diff is broader than the previous targeted patch. It includes updates across AWS Smithy/AWS SDK, HTTP/Hyper, Arrow/Parquet, Futures, Serde, Rustls and other transitive dependencies.

rust/Cargo.lock is the only changed file.

Validation

cargo tree --locked -i h2

resolves to:

h2 v0.4.18

cargo audit

passes with exit code 0.

RUSTSEC-2026-0258 is no longer reported.

The existing allowed warning remains:

RUSTSEC-2024-0436 paste 1.0.15 - unmaintained

cargo check --workspace --locked

passes.

cargo test --workspace --locked -j 1 -- --test-threads=1

passes locally on Windows, including all 9 sleeper_core --test compaction_test integration tests.

An earlier isolated Windows execution reached the sleeper_core compaction tests but failed because aws-smithy-http-client v1.4.0 could not parse native root certificates in that execution environment. Re-running the exact workspace test command directly in the normal local Windows environment passed the full workspace suite, including all 9 compaction tests, so that certificate failure was not reproducible locally.

A separate WSL/Linux run from the same feature commit completed compilation but aborted earlier in rust_sketch, during quantiles::byte_tests::multi_sketch_serialize, where libstdc++ asserted while dereferencing an unengaged std::optional. The process exited with SIGABRT before reaching the compaction tests.

These are distinct failures occurring in different components and do not currently indicate a deterministic failure caused by the generated lockfile.

git diff --check

passes.

Generated lockfile

The Cargo-generated refresh includes 132 package version updates, along with a small number of package additions, removals and dependency-edge changes.

Notable updates include:

• h2 0.4.15 -> 0.4.18
• aws-smithy-http-client 1.2.0 -> 1.4.0
• aws-smithy-runtime 1.12.0 -> 1.14.0
• aws-config 1.10.0 -> 1.11.0
• hyper 1.10.1 -> 1.11.0
• http 1.4.2 -> 1.5.0
• Arrow/Parquet 58.3.0 -> 58.4.0
• Futures 0.3.33 -> 0.3.34
• Serde 1.0.228 -> 1.0.229
• Rustls 0.23.41 -> 0.23.43

These changes are the dependency resolution produced directly by cargo generate-lockfile; they have not been manually minimised or adjusted.

Documentation

• No new functionality is introduced.
• No Java code is changed.
• No source files were modified.
• This PR contains only the Cargo-generated lockfile update.

Notes

The previous patch intentionally updated only the dependency entries required to resolve the advisory.

This replacement instead uses the repository's normal lockfile regeneration workflow as requested during review, while preserving the generated result exactly.

Arguably my proudest contribution so far: running cargo generate-lockfile.

[CJIA-cmd]

Update: the targeted Cargo-generated version has now finished validation and is available on a separate branch:

issue-7945-h2-targeted-cargo-update

It was generated from the same develop baseline using:

cargo update -p h2 --precise 0.4.18

For comparison:

• cargo generate-lockfile: ~132 package version updates and a 766-line Cargo.lock diff
• targeted cargo update: 1 package version update and a 12-line Cargo.lock diff

The targeted update changes h2 0.4.15 -> 0.4.18 and rewires four existing windows-sys dependency edges, with no other package version changes.

Validation

cargo tree --locked -i h2
cargo audit
cargo check --workspace --locked
cargo test --workspace --locked -j 1 -- --test-threads=1
git diff --check

The targeted branch passes the full workspace validation, including all 9 sleeper_core compaction integration tests.

I also checked the targeted commit under WSL/Linux. cargo tree --locked -i h2 and cargo check --workspace --locked pass there, but the workspace test aborts in rust_sketch during quantiles::byte_tests::multi_sketch_serialize with a libstdc++ std::optional assertion and SIGABRT.

A focused sleeper_core compaction test under WSL reaches the same native DataSketches/libstdc++ assertion.

As a control, I reproduced the same rust_sketch failure under the current WSL environment using the historical commit from the original narrow h2 PR. The historical and current targeted lockfiles differ only in h2 0.4.16 -> 0.4.18 plus checksum, with no rust_sketch, DataSketches, native bridge, source, or configuration differences between them.

That indicates the WSL failure is not specific to the current targeted h2 update.

I haven't opened another PR or changed this one. The separate branch is only there for comparison in case the narrower Cargo-generated resolution is preferable.

[patchwork01]

We've got a problem with our vulnerability scanning that we're in the process of resolving. That'll fail the build on this branch right now, so we'll get to this once that's sorted. Thanks for contributing.

[CJIA-cmd]

We've got a problem with our vulnerability scanning that we're in the process of resolving. That'll fail the build on this branch right now, so we'll get to this once that's sorted. Thanks for contributing.

Hey there, that's perfectly fine — this is just a maintenance shuffle, which reminds me why we love Cargo so much. I'm supposed to be on a break but got the RustSec audit email, so I just came to check it out. Hopefully I'm building up to the point where I can get involved with that work too. Hope it resolves neatly!

[rtjd6554]

Issue resolved as part of other rust upgrade actions