[LeeroyHannigan]

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. The server creates these clients only when [backup.store] sets kind = "s3". Each client parses these inputs with it:

• aws-sdk-s3 and aws-sdk-sts: the endpoint partition table only. Each SDK has the table compiled in, unless SMITHY_CLIENT_SDK_CUSTOM_PARTITION names a file. S3 and STS responses are XML.
• aws-sdk-sso and aws-sdk-ssooidc: the partition table, and the responses of the SSO and SSO OIDC endpoints.
• aws-config: the credentials it reads from IMDS, the container credentials endpoint, a credential_process command and the SSO token cache file.

No request to the ExtendDB server reaches aws-smithy-json. Outside tests, crates/backup-store/src/s3.rs is the only file that names an AWS SDK crate, and the DynamoDB API, the admin API and the console parse requests with serde_json. The lock for tests/rust already has 0.62.7.

Since #672 the server links the AWS SDK clients, so the four license notices files list the aws-smithy crates. They now list the new versions.

The minimum Rust version

Four of the six crates declare rustc 1.91.1 as their minimum: aws-smithy-json 0.62.7, aws-smithy-runtime-api 1.12.3, aws-smithy-types 1.4.9 and aws-smithy-async 1.2.14. aws-smithy-runtime-api-macros 1.0.0 declares 1.91.0, and aws-smithy-schema 0.1.0 declares 1.91. Every fixed version of aws-smithy-json declares 1.91.1 or higher: 0.62.7 declares 1.91.1, and 0.63.x and 0.65.x declare 1.94.1. The minimum version 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.
• The example Dockerfile in the deployment guide builds on rust:1.91.1-bookworm. It said to match rust-version and built on rust:1.95. The rust tags without a suffix are the Debian trixie images, and the example's runtime stage is debian:bookworm-slim. The example now uses the bookworm image, as the four Dockerfiles do.
• Three comments on compare-exchange loops name 1.91.1 as the version on which try_update, the replacement for fetch_update, is still unstable.
• 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 lint is in clippy::pedantic, which only extenddb-cache enables. 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. Since #672 the extenddb binary depends on extenddb-backup-store through extenddb-app, so the images and npm binaries built from main link aws-smithy-json 0.62.3. With this change they link 0.62.7.

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 with --locked added: 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.

After merging main at e681b8b:

• The lock differs from main's only in the six aws-smithy crates above.
• cargo tree --locked -p extenddb -i aws-smithy-json -e normal: the binary reaches 0.62.7 through extenddb-app, extenddb-backup-store and aws-config.
• cargo +1.97.0 fmt --all -- --check: pass.
• Both clippy commands in clippy.yml, on 1.97.0 with --locked and -D warnings: pass.
• cargo +1.91.1 check --locked --workspace --all-targets: pass.
• cargo +1.91.1 check --locked -p extenddb --no-default-features, once each with --features mongodb, --features sqlite,dev-mode and --features cassandra: pass, with no warnings. The 1.91.1 leg of test.yml builds the binary with its default postgres feature only.
• cargo +1.91.1 test --locked -p extenddb-backup-store --lib: 37 passed, 0 failed.
• cargo +1.91.1 test --locked -p extenddb-cache --lib: 27 passed, 0 failed.
• devtools/generate-software-license-notices --check for postgres, mongodb and cassandra, and devtools/generate-dev-license-notices --check: pass after the regeneration.
• The pinned rust:1.91.1-bookworm digest is the one Docker Hub serves for that tag today, and public.ecr.aws serves it.

At the head, e2b8daa, on amd64:

• cargo +1.97.0 fmt --all -- --check: pass.
• docker build of Dockerfile, Dockerfile.mongodb and Dockerfile.dev: pass. Pull request CI builds only Dockerfile.cassandra (smoke-cassandra-image.yml), and the release workflows build the other three. The postgres build installs cargo-auditable 0.7.7 on 1.91.1, and the other two builds reuse that layer. All three compile aws-smithy-json 0.62.7.
• docker run --rm --read-only --network none <image> --version for each of the three images: prints extenddb 0.1.14, commit e2b8daa09778 and the build time. No arm64 build of these three images ran.

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.