Add aws-lc-rs and fips features to aws-sigv4 - #1
Merged
jkaczman merged 9 commits intoSep 22, 2026
Merged
Conversation
…mithy-lang#4611) Add CBOR encoding and decoding support for BigInteger using CBOR tags 2 (positive bignum) and 3 (negative bignum) as specified by RFC 8949 §3.4.3 and the Smithy RPC v2 CBOR protocol. - Preferred serialization: values fitting in u64/i64 use major types 0/1 instead of bignum tags - Tag 3 correctly encodes -1-n per RFC 8949 - Handle minicbor Int type for major type 1 values exceeding i64 range - Add num-bigint dependency to aws-smithy-cbor - Codegen: BigIntegerShape delegates to decoder.big_integer() / encoder.big_integer() - BigDecimal remains unsupported with CBOR (fails at codegen time) - Comprehensive tests: round-trip, RFC 8949 Appendix A interop, edge cases Resolves: smithy-rs#4473 ## Motivation and Context BigInteger was previously unsupported with the CBOR protocol — attempting to use a `BigIntegerShape` in a Smithy model with RPC v2 CBOR would fail at codegen time with a `CodegenException`. This blocked any service or client that needed arbitrary-precision integers over CBOR. The Smithy RPC v2 CBOR spec requires BigInteger support via CBOR tags 2 and 3 (RFC 8949 §3.4.3), and this change implements that requirement. See smithy-rs#4473. ## Description **Rust runtime (`aws-smithy-cbor`):** - Added `big_integer()` to `Encoder` — writes values using preferred serialization (major type 0/1 for values fitting u64/i64, tags 2/3 for larger values). Tag 3 encodes the byte string as `n` where the value is `-1 - n` per RFC 8949. - Added `big_integer()` to `Decoder` — reads CBOR tags 2/3 (bignum), plain unsigned/signed integers (major types 0/1), and minicbor `Int` type for major type 1 values exceeding i64 range. - Added `num-bigint` 0.4 dependency for arbitrary-precision integer arithmetic. - Added `strip_leading_zeroes()` helper for preferred bignum serialization. **Codegen (`codegen-core`):** - `CborParserGenerator.kt`: `BigIntegerShape` now emits `decoder.big_integer()` instead of throwing `CodegenException`. - `CborSerializerGenerator.kt`: `BigIntegerShape` now emits `encoder.big_integer()` instead of throwing `CodegenException`. - `BigDecimalShape` remains unsupported (still throws `CodegenException`). ## Testing - 18 new Rust unit tests in `aws-smithy-cbor` covering: - Round-trip encode/decode for positive, negative, and large values - RFC 8949 Appendix A interoperability vectors (2^64, -2^64-1) - Preferred serialization verification (small values use major types 0/1, not tags) - Edge cases: empty byte strings for tags 2/3, invalid tag rejection, major type 1 values exceeding i64 - Leading zero stripping in bignum byte strings - Updated Kotlin codegen tests to verify successful code generation instead of expecting `CodegenException` - All 29 `aws-smithy-cbor` tests pass ## Checklist - [x] For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the `.changelog` directory, specifying "client," "server," or both in the `applies_to` key. ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._ --------- Co-authored-by: Landon James <lnj@amazon.com>
## Motivation and Context Upstream commit bfc80f7 (chromium/badssl.com@bfc80f7) (Jun 1, 2026) added `@SECLEVEL=0` to nginx `ssl_ciphers` directives, which is not recognized by the OpenSSL 1.0.2g we build from source in `new-badssl-dockerfile`. This causes `nginx -t` to fail with `SSL_CIPHER_PROCESS_RULESTR:invalid command`. ## Description Pin `chromium/badssl.com` checkout to commit `6e53ae0` (pre-Ubuntu 24.04 upgrade) to fix the TLS CI build. Opened smithy-lang#4687 as a follow-up. ## Testing - CI ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
…ithy-lang#4680) Bumps [openssl](https://github.com/rust-openssl/rust-openssl) from 0.10.79 to 0.10.80. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rust-openssl/rust-openssl/releases">openssl's releases</a>.</em></p> <blockquote> <h2>openssl-v0.10.80</h2> <h2>What's Changed</h2> <ul> <li>Prefer Homebrew openssl@4 and stop looking for openssl@1.1 by <a href="https://github.com/alex"><code>@alex</code></a> in <a href="https://redirect.github.com/rust-openssl/rust-openssl/pull/2633">rust-openssl/rust-openssl#2633</a></li> <li>Fix output buffer overflow in cipher_update_inplace for AES key-wrap-with-padding by <a href="https://github.com/alex"><code>@alex</code></a> in <a href="https://redirect.github.com/rust-openssl/rust-openssl/pull/2638">rust-openssl/rust-openssl#2638</a></li> <li>Release openssl 0.10.80 and openssl-sys 0.9.116 by <a href="https://github.com/alex"><code>@alex</code></a> in <a href="https://redirect.github.com/rust-openssl/rust-openssl/pull/2639">rust-openssl/rust-openssl#2639</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/rust-openssl/rust-openssl/compare/openssl-v0.10.79...openssl-v0.10.80">https://github.com/rust-openssl/rust-openssl/compare/openssl-v0.10.79...openssl-v0.10.80</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rust-openssl/rust-openssl/commit/35be7ae43b207fc0448a648a21e9156bc360c9af"><code>35be7ae</code></a> Release openssl 0.10.80 and openssl-sys 0.9.116 (<a href="https://redirect.github.com/rust-openssl/rust-openssl/issues/2639">#2639</a>)</li> <li><a href="https://github.com/rust-openssl/rust-openssl/commit/19eceb26f2404aae187e5444e65c404ebc1348a7"><code>19eceb2</code></a> Fix output buffer overflow in cipher_update_inplace for AES key-wrap-with-pad...</li> <li><a href="https://github.com/rust-openssl/rust-openssl/commit/b460eb378c335610df5395a251408ad70bb60d42"><code>b460eb3</code></a> Prefer Homebrew openssl@4 and stop looking for openssl@1.1 (<a href="https://redirect.github.com/rust-openssl/rust-openssl/issues/2633">#2633</a>)</li> <li>See full diff in <a href="https://github.com/rust-openssl/rust-openssl/compare/openssl-v0.10.79...openssl-v0.10.80">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/smithy-lang/smithy-rs/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Aaron Todd <aajtodd@users.noreply.github.com>
…hy-lang#4691) ## Motivation and Context smithy-lang#3370 ## Description This PR lifts the restriction that `aws-smithy-eventstream` can only receive patch version bumps in `Cargo.toml`, which has prevented the crate from receiving minor version bumps, let alone becoming stable. The root cause is that `DeferredSignerSender`, a type stored in `ConfigBag`, is defined in `aws-smithy-eventstream` (an unstable 0.x crate). If the crate receives a minor bump (e.g., 0.60 → 0.61), Cargo treats these as semver-incompatible for 0.x crates and allows both to coexist in the dependency graph. Since `ConfigBag` uses `TypeId` for lookups, the old version's type differs from the new version's type, causing silent lookup failures that break event stream signing. The fix moves `DeferredSignerSender` and the `SignMessage` trait to `aws-smithy-types` (a stable 1.x crate). This is the only place in the crate hierarchy that avoids circular dependencies (and already has an `event_stream` module). Changes: - `aws-smithy-types` (bumped to 1.5.0): Add `DeferredSignerSender`, `DeferredSignerReceiver`, `SignMessage`, and associated error types to the existing `event_stream` module. - `aws-smithy-eventstream` (bumped to 0.60.21, still a patch version bump): Remove old `DeferredSignerSender` definition, re-export from `aws-smithy-types`. Adapt `DeferredSigner` to use `DeferredSignerReceiver`. - `aws-runtime` (bumped to 1.7.5): Import `DeferredSignerSender` from `aws-smithy-types` instead of `aws-smithy-eventstream`. - Remove the "only patch releases" restriction comment from `aws-smithy-eventstream/Cargo.toml`. ~**Note on `send` method signature change**: The `send` method on `DeferredSignerSender` previously took `Box<dyn SignMessage + Send + Sync>` directly. Since moving the `SignMessage` trait to `aws-smithy-types` requires stabilizing the trait, the new `send` is generic (`send<T: Send + Sync + 'static>`) with the value type-erased internally via `Box<dyn Any>`. This changes the method signature, but `send` is only called internally by `aws-runtime`; verified this via internal code search and public GitHub search. An alternative would be to also move `SignMessage` to `aws-smithy-types` to preserve the `send` method signature, but at the cost of committing to stabilizing the trait.~ ## Testing - CI - `cargo-semver-checks` reports `struct_missing` for `DeferredSignerSender` in `aws-smithy-eventstream` — this is expected, and the struct is replaced by a re-export from `aws-smithy-types` at the same path; the tool does not follow cross-crate re-exports of types. - Manual standalone test (uncommitted) that reproduces the hazard and verifies the fix <details> <summary>Standalone test crate details</summary> The test simulates two versions of `aws-smithy-eventstream` coexisting in a dependency graph — an SDK on 0.60.x and that on 0.61.0. It stores a `DeferredSignerSender` via the "old" eventstream and loads it via `aws-smithy-types` (as the new runtime would). **Setup**: ``` $ cd semver-test # Bump local eventstream to 0.61.0 to simulate a future minor bump $ sed -i '' 's/0.60.21/0.61.0/' ../rust-runtime/aws-smithy-eventstream/Cargo.toml # Create fake-0.60.21/ — a copy of the fixed eventstream at version 0.60.21 # (simulates what old SDKs resolve to after cargo update picks up the fix) $ cp -r ../rust-runtime/aws-smithy-eventstream ./fake-0.60.21 $ sed -i '' 's/0.61.0/0.60.21/' ./fake-0.60.21/Cargo.toml ``` `semver-test/src/main.rs` (shared by both cases): ``` use aws_smithy_types::config_bag::{ConfigBag, Layer}; use aws_smithy_types::event_stream::DeferredSignerSender; fn main() { // "Old SDK" stores DeferredSignerSender via eventstream let (_signer, sender) = aws_smithy_eventstream_old::frame::DeferredSigner::new(); let mut layer = Layer::new("test"); layer.store_put(sender); let bag = ConfigBag::of_layers(vec![layer]); // "New runtime" loads via aws-smithy-types directly let loaded = bag.load::<DeferredSignerSender>(); assert!(loaded.is_some(), "SEMVER HAZARD: TypeId mismatch!"); println!("SUCCESS: DeferredSignerSender survives across eventstream version boundary!"); } ``` **Step 1: Reproduce the hazard (before fix)** Uses crates.io's 0.60.20 as the "old" dep — this version defines its own `DeferredSignerSender`: ``` [dependencies] aws-smithy-eventstream-old = { package = "aws-smithy-eventstream", version = "0.60.20" } # Local eventstream at 0.61.0 (simulates the minor bump) aws-smithy-eventstream-new = { package = "aws-smithy-eventstream", path = "../rust-runtime/aws-smithy-eventstream" } aws-smithy-types = { path = "../rust-runtime/aws-smithy-types" } [patch.crates-io] # Unifies aws-smithy-types — simulates 1.5.0 published on crates.io aws-smithy-types = { path = "../rust-runtime/aws-smithy-types" } ``` ``` $ cargo run SEMVER HAZARD: TypeId mismatch! ``` **Step 2: Verify the fix (simulating after 0.60.21 published)** Uses fake-0.60.21/ as the "old" dep — same fixed code, just at version 0.60.21 (uses `DeferredSignerSender` from `aws-smithy-types`): ``` [dependencies] aws-smithy-eventstream-old = { package = "aws-smithy-eventstream", path = "./fake-0.60.21" } # Local eventstream at 0.61.0 (simulates the minor bump) aws-smithy-eventstream-new = { package = "aws-smithy-eventstream", path = "../rust-runtime/aws-smithy-eventstream" } aws-smithy-types = { path = "../rust-runtime/aws-smithy-types" } # No [patch.crates-io] needed — all deps are local paths, single aws-smithy-types resolved naturally ``` ``` $ cargo run SUCCESS: DeferredSignerSender survives across eventstream version boundary! ``` **Revert after testing:** `$ sed -i '' 's/0.61.0/0.60.21/' ../rust-runtime/aws-smithy-eventstream/Cargo.toml` ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
…thy-lang#4694) If CI fails, commit the necessary fixes to this PR until all checks pass. If changes are required to [crateNameToLastKnownWorkingVersions](https://github.com/smithy-lang/smithy-rs/blob/92916b5484cdfef9ff58540ebf5e845eeeccf860/aws/sdk/build.gradle.kts#L504), revert the first commit in the PR, run `./gradlew aws:sdk:cargoUpdateAllLockfiles`, and commit the updated lockfiles.
…ang#4699) Closes smithy-lang#4698. ## Motivation and Context time 0.3.48 added impl From<T> for <T as ModifierValue>::Type (time-rs/time#783), which conflicts with any local blanket impl<T> From<T> and breaks the build with E0119: ``` error[E0119]: conflicting implementations of trait `From<...HourBase>` = note: conflicting implementation in crate `time` ``` smithy-rs has several such blanket impls, so it breaks wherever time resolves fresh to 0.3.48 (generated SDK build, TLS job, etc.). ## Description Fix at the dependency layer instead of narrowing every blanket impl (whack-a-mole + public-API breaks): - **Constrain time to `<0.3.48`** in aws-smithy-types. Everything routes through it, so cargo's version intersection forces time `0.3.47` across all build paths (and it's copied verbatim into the generated SDK). - **Defense in depth:** pin time →` 0.3.47` in the broken-dependency map in aws/sdk/build.gradle.kts. - **Hygiene:** make the private CanDisable blanket concrete (From<Duration>). No public API changes. ## Testing - cargo update -p time holds at 0.3.47 (not 0.3.48) in both workspaces. - E2E:` ./gradlew :aws:sdk:assemble`; generated aws-smithy-types/Cargo.toml carries the bound; in the generated SDK, cargo check -p aws-smithy-runtime-api compiles with no E0119. - cargo fmt --check, runtime-versioner audit, sdk-lints pass. - **Check PR semver compliance fails as a false positive:** cargo-semver-checks builds the main baseline, which predates the constraint and can't compile against time 0.3.48. Not an API break (only private CanDisable changed); resolves once this lands on main or time 0.3.49 ships. ## Checklist - [x] Changelog entry added for client/server (applies_to). - [x] Changelog entry added for aws-sdk-rust. By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
## Motivation and Context Upgrade the MSRV to 1.94.1. Per [feedback from a customer](smithy-lang#4578), this PR bumps minor versions across crates, regardless of whether stable or unstable. ## Description The following is a list of CI failures addressed during the MSRV upgrade: ### Compiler lint fixes - `unused_imports` in `coalesce.rs` / `ite.rs` — Removed `use super::*` from test modules. Rust 1.94 correctly identifies that macros re-exported with pub(crate) use are already in scope without an explicit import. ``` error: unused import: `super` --> sdk/s3/src/endpoint_lib/coalesce.rs:103:9 ``` - `clippy::unnecessary_unwrap` in `aws-smithy-eventstream` — Restructured `acquire()` to use early-return pattern instead of `is_some()/unwrap()`. ``` error: called `unwrap` on `self.signer` after checking its variant with `is_some` --> aws-smithy-eventstream/src/frame.rs:111:13 ``` - `unused_assignments` in generated server protocol tests — Rust 1.94 flags the moved sender in async closures as "value captured is never read" since `send()` only borrows it. Fixed by placing `#[allow(unused_assignments)]` on the closure expression. ``` error: value captured by `sender` is never read --> rest_json/rust-server-codegen/src/operation.rs:45822:37 | 45822 | ... sender.send(()).await.expect("receiver dropped early"); | ^^^^^^ | = help: did you mean to capture by reference instead? ``` - `unused_imports` in `retry.rs` — Removed unused `error` from tracing import. ``` error: unused import: `error` --> smithy-rs-tool-common/src/retry.rs:9:15 ``` - `unused_imports` on Windows — Moved `SystemTime`, `Rfc3339`, and `OffsetDateTime` imports inside cfg-gated test functions so they're only compiled when the test is active. ``` error: unused import: `time::format_description::well_known::Rfc3339` --> aws-smithy-types\src\date_time\mod.rs:396:9 ``` ### Test fixes - `system_time_conversions` / `date_format` / `date_time_format` panics on Windows — Added `target_os = "windows"` to cfg exclusions. The `time` crate's `SystemTime::from(OffsetDateTime)` panics for pre-1601 dates on Windows because `SystemTime` is backed by `FILETIME` (epoch 1601). The test oracle panics while constructing the expected value; our production code handles this correctly via `checked_sub` → `Err`. ``` thread 'date_time::test::system_time_conversions' panicked at std\src\time.rs:712:31: overflow when subtracting duration from instant ``` ### CI/tooling updates - Dockerfile — added `aarch64-unknown-linux-musl` target, bumped `cargo-check-external-types` to 0.5.0. - `ci.yml` / `manual-canary.yml` — Updated hardcoded toolchain from 1.91.1 to 1.94.1 for the aarch64 canary jobs. ``` error[E0463]: can't find crate for core = note: the aarch64-unknown-linux-musl target may not be installed ``` - `pull-request-bot.yml` — Updated `rust_nightly_version` to nightly-2026-03-20. ### Design book doctests - Marked 6 code blocks in `design/src/server/anatomy.md` and `middleware.md` as `rust,ignore`. The shared `target-dir` in `.cargo/config.toml` causes both `http 0.2` and `http 1.x` rlibs to exist in `target/debug/deps/`, making `extern crate http` ambiguous. ``` error[E0464]: multiple candidates for rlib dependency http found --> /tmp/mdbook-J98CBh/server/anatomy.md:677:1 = note: candidate smithy-lang#1: target/debug/deps/libhttp-3d1c53169010d178.rlib = note: candidate smithy-lang#2: target/debug/deps/libhttp-654580366553cb9a.rlib ``` ### Semver/version bumps - `aws-smithy-schema` — Changed from 0.1.0 to 0.1.1. A minor bump on a 0.x crate is semver-incompatible with `^0.1` required by released `aws-config`, causing the semver hazards check to fail. When we ship schema serde, we make `aws-smithy-schema` 1.x, after which we can bump minor for MSRV upgrades. ``` error[E0308]: mismatched types --> aws-config-1.8.18/src/lib.rs:999:34 note: there are multiple different versions of crate aws_smithy_schema in the dependency graph ``` ## Testing - CI ## Checklist - [x] For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the `.changelog` directory, specifying "client," "server," or both in the `applies_to` key. - [x] For changes to the AWS SDK, generated SDK code, or SDK runtime crates, I have created a changelog entry Markdown file in the `.changelog` directory, specifying "aws-sdk-rust" in the `applies_to` key. ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
Route SigV4 HMAC-SHA256 / SHA-256 and (when combined with sigv4a) SigV4a ECDSA-P256 through aws-lc-rs (or aws-lc-fips-sys) when the new features are enabled, mirroring the additive __rustls / rustls-aws-lc / rustls-aws-lc-fips pattern in aws-smithy-http-client and the companion PR smithy-lang#4690 for aws-smithy-checksums. The default build is unchanged and keeps the existing hmac / sha2 / p256 (RustCrypto) path; the new features are strictly opt-in. This is the aws-sigv4 half of smithy-rs#4681. With both halves landed, FIPS-conscious customers can route TLS, request checksums, and request signing end-to-end through aws-lc-rs without forking the runtime crates. An internal __aws-lc-rs feature gates every swapped code path; the public aws-lc-rs and fips features each select the aws-lc-rs backend explicitly (aws-lc-sys vs aws-lc-fips-sys). Source-level cfgs ensure that when __aws-lc-rs is active, no RustCrypto cryptographic code path is executed for SigV4 or SigV4a, even when sigv4a is also enabled. For the SigV4a ECDSA path, the existing 32-byte deterministic scalar contract from generate_signing_key is preserved. calculate_signature wraps the scalar in a minimal 51-byte RFC 5915 SEC1 ECPrivateKey DER (publicKey field intentionally omitted) and hands it to EcdsaKeyPair::from_private_key_der, which lets AWS-LC derive the public point internally — no p256 code path is required. Verified on macOS (aarch64-apple-darwin): - cargo test -p aws-sigv4 (default, RustCrypto) 89 ok - cargo test -p aws-sigv4 --features sigv4a 124 ok - cargo test -p aws-sigv4 --features aws-lc-rs 89 ok - cargo test -p aws-sigv4 --features "aws-lc-rs sigv4a" 124 ok - cargo build -p aws-sigv4 --features "fips sigv4a" ok - cargo clippy -p aws-sigv4 --features "aws-lc-rs sigv4a" --all-targets -- -D warnings clean
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an unmerged PR into smithy-rs that someone created (but didn't try to merge, as the maintainers didn't want to support the extra feature). Going to see if I can work off of this.