Skip to content

fix(deps): update aws-smithy-json to 0.62.7 and raise the minimum Rust version to 1.91.1 - #857

Open
LeeroyHannigan wants to merge 6 commits into
mainfrom
deps/aws-smithy-json-0.62.7
Open

LeeroyHannigan wants to merge 6 commits into
mainfrom
deps/aws-smithy-json-0.62.7

Conversation

@LeeroyHannigan

Copy link
Copy Markdown
Collaborator

What

Cargo.lock moves aws-smithy-json from 0.62.3 to 0.62.7, the first version with the fix for Dependabot alert 19. The minimum Rust version of the workspace moves from 1.88 to 1.91.1, because 0.62.7 needs it.

The lock

0.62.7 requires aws-smithy-runtime-api 1.12.3 or newer, so the lock also moves aws-smithy-runtime-api from 1.11.3 to 1.12.3, aws-smithy-types from 1.4.3 to 1.4.9 and aws-smithy-async from 1.2.11 to 1.2.14. It adds aws-smithy-runtime-api-macros 1.0.0 and aws-smithy-schema 0.1.0. Each is the lowest version the new requirements accept. No other package moves. Each aws-smithy crate resolves to one version.

In this workspace only the AWS SDK clients behind extenddb-backup-store use aws-smithy-json: aws-config, aws-sdk-s3, aws-sdk-sso, aws-sdk-ssooidc and aws-sdk-sts. They use it to parse the responses of the S3, STS and SSO endpoints the operator configures. The lock for tests/rust already has 0.62.7.

The minimum Rust version

The six crates declare rustc 1.91.1 as their minimum. Every fixed version of aws-smithy-json has that floor or a higher one: 0.62.7 declares 1.91.1, and 0.63.x and 0.65.x declare 1.94.1. The other five commits raise the workspace minimum to match:

  • Cargo.toml sets rust-version to 1.91.1. The comment on the aws-sdk pins now says that each pinned version declares a minimum at or below the workspace rust-version.
  • The 1.88.0 leg of test.yml runs on 1.91.1. .cargo/config.toml names 1.91.1 for the resolver fallback.
  • The four Dockerfiles build on rust:1.91.1-bookworm, pinned by digest. Cargo refuses to build a package on a compiler older than its rust-version, so the 1.88 build stage would fail on every image.
  • README.md, CONTRIBUTING.md, AGENTS.md, the getting started page, the quick start and install manuals, the backup design and the setup references name 1.91.1.
  • Two comments say that the replacement for fetch_update, try_update, does not exist on 1.91.1. It is still unstable there.
  • clippy reads the minimum from rust-version, and from 1.91 it asks for Duration::from_mins where a value is a whole number of minutes. The three cases are in extenddb-cache: the default TTL in swr.rs and two lines of tests.rs now use Duration::from_mins(1).

The release images change compiler, from 1.88 to 1.91.1. On main they build only the extenddb binary, which does not depend on extenddb-backup-store. #672 adds that dependency, so this change comes before the backup work ships the AWS SDK in the server.

Why

Dependabot alert 19 (high) covers CVE-2026-18140, GHSA-8ffr-xgwf-xj56. Versions of aws-smithy-json up to 0.62.6 recurse without a depth limit while they skip an unknown key. A deeply nested document can exhaust the stack. The first version with the fix is 0.62.7.

No issue. The alert is at https://github.com/ExtendDB/extenddb/security/dependabot/19.

Testing done

The lock commit, on stable (1.99.0):

  • cargo tree -i aws-smithy-json --locked: one version, 0.62.7, reached through aws-config, aws-sdk-s3, aws-sdk-sso, aws-sdk-ssooidc and aws-sdk-sts.
  • cargo check --locked --workspace: pass.
  • cargo test --locked -p extenddb-backup-store --lib: 33 passed, 0 failed.
  • cargo test --locked -p extenddb-backup-store --test conformance: the S3 tests skip without EXTENDDB_TEST_S3_ENDPOINT. The filesystem tests need a temporary directory whose ancestors belong to root or to the test user. The build host has no such directory, so CI runs them.

The minimum version commits:

  • cargo +1.97.0 fmt --all -- --check: pass.
  • cargo +1.91.1 check --locked --workspace --all-targets: pass.
  • cargo +1.91.1 test --locked -p extenddb-backup-store --lib: 33 passed, 0 failed.
  • cargo +1.88.0 check --locked -p extenddb: refused, "extenddb-server@0.1.14 requires rustc 1.91.1", as expected.
  • cargo +1.97.0 clippy --locked --all-targets --features extenddb-storage-cassandra/test-hooks,extenddb-storage-mongodb/test-hooks -- -D warnings, the CI command: pass after the three Duration changes. Before them it failed on clippy::duration_suboptimal_units in extenddb-cache.
  • cargo +1.91.1 test --locked -p extenddb-cache --lib: 27 passed, 0 failed.

Checklist

  • I have read CONTRIBUTING.md
  • All tests pass (cargo test --workspace)
  • Code is formatted (cargo fmt --check)
  • Clippy is clean (cargo clippy -- -W clippy::pedantic)
  • I have added or updated tests for new functionality
  • I have updated documentation if behavior changed
  • Breaking changes are noted below (if any)
  • If this changes the wire protocol, Storage trait, auth model, on-disk
    format, or public CLI surface, an RFC has been accepted or is linked
    below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a

Breaking changes

Building ExtendDB from source needs Rust 1.91.1 or newer. An older toolchain stops with "requires rustc 1.91.1". Users of the published images and npm packages need no new toolchain, because CI builds them.


By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

Cargo.lock: aws-smithy-json moves from 0.62.3 to 0.62.7. Versions up to
0.62.6 recurse without a depth limit while skipping an unknown key, so a
deeply nested document can exhaust the stack (CVE-2026-18140,
GHSA-8ffr-xgwf-xj56). In this workspace only the AWS SDK clients behind
extenddb-backup-store (aws-config, aws-sdk-s3, aws-sdk-sso,
aws-sdk-ssooidc, aws-sdk-sts) use the crate, to parse the responses of
the S3, STS and SSO endpoints the operator configures.

0.62.7 requires aws-smithy-runtime-api 1.12.3 or newer, so the lock also
moves aws-smithy-runtime-api from 1.11.3 to 1.12.3, aws-smithy-types
from 1.4.3 to 1.4.9 and aws-smithy-async from 1.2.11 to 1.2.14, and adds
aws-smithy-runtime-api-macros 1.0.0 and aws-smithy-schema 0.1.0. Each is
the lowest version the new requirements accept. No other package moves,
and each aws-smithy crate resolves to one version.

The six crates declare rustc 1.91.1 as their minimum, above the
workspace rust-version of 1.88, so a 1.88 toolchain refuses to build
extenddb-backup-store with this lock. The release images build only the
extenddb binary, which does not depend on extenddb-backup-store, so they
are unaffected.
aws-smithy-json 0.62.7, the first release with the fix for
CVE-2026-18140, and the five aws-smithy crates it needs declare rustc
1.91.1 as their minimum. The workspace minimum was 1.88.

Cargo.toml sets rust-version to 1.91.1. The comment on the aws-sdk pins
now says that each pinned version declares a minimum at or below the
workspace rust-version, and .cargo/config.toml names 1.91.1 for the
resolver fallback.

The comments next to the two compare-exchange loops that stand in for
fetch_update now name 1.91.1: the replacement, try_update, is still
unstable there.

clippy reads the minimum from rust-version, and from 1.91 it asks for
Duration::from_mins where a value is a whole number of minutes. The
three cases are in extenddb-cache: the default TTL in swr.rs and two
lines of tests.rs now use Duration::from_mins(1).
The workspace rust-version is 1.91.1, so the leg that checks the
minimum moves from 1.88.0 to 1.91.1.
README.md, CONTRIBUTING.md, the getting started page, the quick start
and install manuals and the backup design name 1.91.1, the workspace
rust-version.
The four Dockerfiles build on rust:1.91.1-bookworm, pinned by digest.
Cargo refuses to build a package on a compiler older than its
rust-version, so the 1.88 build stage would fail on every image.
AGENTS.md and the setup references under .agents/skills name 1.91.1,
the workspace rust-version.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant