Tags: aws/aws-lc
Tags
Make FIPS compiler wrapper unconditional (#3269) ### Issues: Addresses #3261 ### Description of changes: The `bcm_c_generated_asm` target uses `COMPILE_OPTIONS "-S"` on a CMake static library, which causes CMake to emit both `-S` and `-c` in the same compile command. These flags are semantically contradictory (`-S` = emit assembly, `-c` = emit object code). GCC and older Clang silently let `-S` win, but Zig produces an object file instead of textual assembly, causing `delocate` to fail with a parse error. We already had a `CompilerWrapper` that strips `-c` when `-S` is present, but it was gated to only activate for Clang ≥ 20. This change removes the version check so the wrapper applies unconditionally, making the build correct for all compilers. ### Call-outs: This fixes the immediate build failure reported in #3261 but does not guarantee full end-to-end FIPS support with Zig. Other parts of the delocate pipeline (e.g., `-E -dI` preprocessing, assembly parsing) haven't been validated with Zig yet. ### Testing: Verified that CMake configure succeeds for the `FIPS_DELOCATE` path and that the wrapper is generated and applied to `bcm_c_generated_asm`. Existing CI (including the Zig workflow and FIPS builds with GCC/Clang) will exercise both sides. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
[CHERYPICK FIPS 4.0] Make rustfmt optional for Rust bindings generati… …on (#3270) (#3272) Cherrypick of #3270 onto `fips-2025-09-12-lts`. ----- ### Description of changes: Configuring with `-DGENERATE_RUST_BINDINGS=ON` currently hard-fails if `rustfmt` isn't on `PATH`. This PR makes `rustfmt` optional: we still probe for it, but only pass `--formatter rustfmt` to bindgen when it's found. When it isn't, bindgen falls back to its built-in `prettyplease` formatter and the build proceeds. ### Call-outs: `prettyplease` and `rustfmt` produce slightly different output, so bindings generated on a machine without `rustfmt` will have cosmetic differences from ones generated in an environment where `rustfmt` is available. ### Testing: Existing CI exercises the `rustfmt`-present path. Locally verified that `cmake -DGENERATE_RUST_BINDINGS=ON ...` configures and the bindings target builds both with `rustfmt` on `PATH` and with it removed. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
Fix CRL distribution point scope check logic in crl_crldp_check (#3105) Commit authored by @nebeid. ### Description of changes: A logic error in `crl_crldp_check()` (`crypto/x509/x509_vfy.c`) prevents CRL distribution point matching from ever running for normal certificates. When a CRL has an Issuing Distribution Point (IDP) extension, the CRL is incorrectly considered out of scope and a revoked certificate escapes detection. Three bugs in one condition: 1. `&&` should be `||` — the comment says skip DPs with `reasons` OR `CRLissuer`, but the code only triggers when BOTH are present. 2. `return 1` should be `continue` — when the condition matches, the code declares the CRL in scope instead of skipping the DP. 3. `idp_check_dp` is in the wrong branch — it only runs for DPs with `reasons`+`CRLissuer`, never for normal clean DPs. ### Fix Took upstream commit 5386d90. ### Testing Two test scenarios added in `crypto/x509/x509_test.cc`: **Scenario 1: Cert with a single clean CRLDP + CRL with matching IDP** Leaf has a clean CRLDP (distpoint URI only, no `reasons`, no `CRLissuer`). CRL has a matching IDP and revokes the leaf's serial. - Before fix: `idp_check_dp` is never called for clean DPs → CRL is out-of-scope. - After fix: `idp_check_dp` matches the distpoints → CRL in scope → `CERT_REVOKED`. **Scenario 2: Cert with two DPs + two CRLs** Leaf has two distribution points: - DP1: `distpoint` matching CRL-B IDP + `reasons` + `CRLissuer` (should be skipped) - DP2: clean `distpoint` (matches the revoking CRL-A) CRL-A (matching IDP) revokes the leaf. CRL-B (other IDP) has no revocations. - Before fix: - DP1 has `reasons`+`CRLissuer` so the `&&` condition is true. `idp_check_dp` matches DP1 against CRL-B → `return 1` → CRL-B is in scope → no revocations → cert appears valid. - DP2 never gets checked against CRL-A; it's skipped both by the `&&` check and by the fallback because it has an IDP. - After fix: - DP1 is skipped (`||` catches `reasons`). - DP2 matches CRL-A via `idp_check_dp` → `CERT_REVOKED`. PoC output without fix: ``` Scenario 1: Cert with clean CRLDP (distpoint only) + CRL with matching IDP Result: 44 (Different CRL scope) FAIL: Expected CERT_REVOKED (23), got 44 Scenario 2: Cert with two DPs (reasons+CRLissuer DP and clean DP) + two CRLs Result: 0 (ok) FAIL: Expected CERT_REVOKED (23), got 0 ``` PoC output with fix: ``` Scenario 1: Cert with clean CRLDP (distpoint only) + CRL with matching IDP Result: 23 (certificate revoked) PASS: Revoked cert correctly detected Scenario 2: Cert with two DPs (reasons+CRLissuer DP and clean DP) + two CRLs Result: 23 (certificate revoked) PASS: Revoked cert correctly detected ``` By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license. Co-authored-by: Nevine Ebeid <66388554+nebeid@users.noreply.github.com>
Fix CRL distribution point scope check logic in crl_crldp_check (#3106) Commit authored by @nebeid. ### Description of changes: A logic error in `crl_crldp_check()` (`crypto/x509/x509_vfy.c`) prevents CRL distribution point matching from ever running for normal certificates. When a CRL has an Issuing Distribution Point (IDP) extension, the CRL is incorrectly considered out of scope and a revoked certificate escapes detection. Three bugs in one condition: 1. `&&` should be `||` — the comment says skip DPs with `reasons` OR `CRLissuer`, but the code only triggers when BOTH are present. 2. `return 1` should be `continue` — when the condition matches, the code declares the CRL in scope instead of skipping the DP. 3. `idp_check_dp` is in the wrong branch — it only runs for DPs with `reasons`+`CRLissuer`, never for normal clean DPs. ### Fix Took upstream commit 5386d90. ### Testing Two test scenarios added in `crypto/x509/x509_test.cc`: **Scenario 1: Cert with a single clean CRLDP + CRL with matching IDP** Leaf has a clean CRLDP (distpoint URI only, no `reasons`, no `CRLissuer`). CRL has a matching IDP and revokes the leaf's serial. - Before fix: `idp_check_dp` is never called for clean DPs → CRL is out-of-scope. - After fix: `idp_check_dp` matches the distpoints → CRL in scope → `CERT_REVOKED`. **Scenario 2: Cert with two DPs + two CRLs** Leaf has two distribution points: - DP1: `distpoint` matching CRL-B IDP + `reasons` + `CRLissuer` (should be skipped) - DP2: clean `distpoint` (matches the revoking CRL-A) CRL-A (matching IDP) revokes the leaf. CRL-B (other IDP) has no revocations. - Before fix: - DP1 has `reasons`+`CRLissuer` so the `&&` condition is true. `idp_check_dp` matches DP1 against CRL-B → `return 1` → CRL-B is in scope → no revocations → cert appears valid. - DP2 never gets checked against CRL-A; it's skipped both by the `&&` check and by the fallback because it has an IDP. - After fix: - DP1 is skipped (`||` catches `reasons`). - DP2 matches CRL-A via `idp_check_dp` → `CERT_REVOKED`. PoC output without fix: ``` Scenario 1: Cert with clean CRLDP (distpoint only) + CRL with matching IDP Result: 44 (Different CRL scope) FAIL: Expected CERT_REVOKED (23), got 44 Scenario 2: Cert with two DPs (reasons+CRLissuer DP and clean DP) + two CRLs Result: 0 (ok) FAIL: Expected CERT_REVOKED (23), got 0 ``` PoC output with fix: ``` Scenario 1: Cert with clean CRLDP (distpoint only) + CRL with matching IDP Result: 23 (certificate revoked) PASS: Revoked cert correctly detected Scenario 2: Cert with two DPs (reasons+CRLissuer DP and clean DP) + two CRLs Result: 23 (certificate revoked) PASS: Revoked cert correctly detected ``` By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license. Co-authored-by: Nevine Ebeid <66388554+nebeid@users.noreply.github.com>
PreviousNext