Merge branch 'main' into quote-libcrypto-path

Author: WillChilds-Klein

.github/workflows/cross-test.yml

@@ -54,7 +54,7 @@ jobs:
           sudo apt-get -y install qemu-user qemu-user-binfmt
       - uses: actions/checkout@v6
       - name: PPC64LE Build/Test
-        run: tests/ci/run_cross_tests.sh ppc64le powerpc64le-unknown-linux-gnu "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_BUILD_TYPE=Release -DFIPS=1 -DBUILD_SHARED_LIBS=1"
+        run: tests/ci/run_cross_tests.sh ppc64le powerpc64le-unknown-linux-gnu "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_BUILD_TYPE=Release -DFIPS=1 -DBUILD_SHARED_LIBS=1" "-DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS=-DOPENSSL_GETAUXVAL_FORCE_PROC_FALLBACK"
   riscv64-non-fips-build-test:
     if: github.repository_owner == 'aws'
     runs-on: ubuntu-24.04
@@ -84,6 +84,35 @@ jobs:
       - uses: actions/checkout@v6
       - name: armv6 Build/Test
         run: tests/ci/run_cross_tests.sh armv6 armv6-unknown-linux-gnueabi "-DCMAKE_BUILD_TYPE=Release"
+  armv7-uclibc-build-test:
+    # Bootlin 2022.08-1 ships uclibc-ng 1.0.42, which predates uclibc-ng's
+    # own <sys/auxv.h> (added in 1.0.43). On this sysroot,
+    # __has_include(<sys/auxv.h>) in cpu_getauxval_linux.h evaluates false,
+    # so natural detection lands on the /proc/self/auxv fallback -- exactly
+    # the scenario from https://github.com/aws/aws-lc/issues/3188. A single
+    # job thus covers both the non-glibc detection path and the fallback
+    # code path end-to-end. If this toolchain is ever bumped to a release
+    # that does ship <sys/auxv.h>, the "INFO:" line in
+    # run_cross_tests_bootlin.sh will make the coverage loss visible in the
+    # CI log.
+    if: github.repository_owner == 'aws'
+    runs-on: ubuntu-24.04
+    steps:
+      - name: Install qemu
+        run: |
+          sudo apt-get update -o Acquire::Languages=none -o Acquire::Translation=none
+          sudo apt-get -y install qemu-user qemu-user-binfmt
+      - uses: actions/checkout@v6
+      - name: armv7 uclibc Build/Test
+        run: |
+          tests/ci/run_cross_tests_bootlin.sh \
+            armv7 \
+            armv7-eabihf--uclibc--stable-2022.08-1 \
+            arm-buildroot-linux-uclibcgnueabihf \
+            tar.bz2 \
+            9e4191ab996fdf5f4e8de7e4617c67cbf46127ca2754fca0ad45d60e393ace05 \
+            arm \
+            "-DCMAKE_BUILD_TYPE=Release"
   loongarch64-non-fips-build-test:
     runs-on: ubuntu-24.04
     steps:

.github/workflows/security-review.yml

@@ -0,0 +1,84 @@
+name: security-review
+
+on:
+  pull_request_target:
+    branches: ["*"]
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref_name }}
+  cancel-in-progress: true
+permissions:
+  contents: read
+
+jobs:
+  authorize:
+    runs-on: ubuntu-latest
+    outputs:
+      approval-env: ${{ steps.authorization.outputs.approval-env }}
+    steps:
+      - uses: actions/checkout@v6
+      - name: Check authorization
+        id: authorization
+        uses: ./.github/actions/check-authorization
+
+  execute:
+    needs: authorize
+    runs-on: ubuntu-latest
+    environment: ${{ needs.authorize.outputs.approval-env }}
+    permissions:
+      id-token: write
+      contents: read
+      statuses: write
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+
+      - name: Get AWS credentials
+        uses: aws-actions/configure-aws-credentials@v6
+        with:
+          role-to-assume: arn:aws:iam::547182295936:role/SecurityReview-GitHubOIDCRole #TODO: migrate to production account
+          role-session-name: ${{ github.run_id }}-${{ github.run_attempt }}
+          aws-region: us-west-2
+
+      - name: Start CodeBuild and wait for completion
+        id: codebuild
+        shell: bash
+        env:
+          PROJECT_NAME: SecurityReview-${{ github.event.repository.name }}
+          SOURCE_VERSION: "pr/${{ github.event.pull_request.number }}"
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+        run: |
+          # Start the build
+          BUILD_ID=$(aws codebuild start-build \
+            --project-name "${PROJECT_NAME}" \
+            --source-version "${SOURCE_VERSION}" \
+            --environment-variables-override "name=PR_NUMBER,value=${PR_NUMBER},type=PLAINTEXT" \
+            --query 'build.id' --output text)
+
+          # Wait for completion
+          while STATUS=$(aws codebuild batch-get-builds --ids "${BUILD_ID}" --query 'builds[0].buildStatus' --output text); [[ "$STATUS" == "IN_PROGRESS" ]]; do
+            sleep 30
+          done
+
+          if [[ "$STATUS" != "SUCCEEDED" ]]; then
+            echo "blocking=skip" >> "$GITHUB_OUTPUT"
+            exit 1
+          fi
+
+          REVIEW_STATUS=$(aws codebuild batch-get-builds --ids "${BUILD_ID}" --query 'builds[0].exportedEnvironmentVariables[?name==`REVIEW_STATUS`].value' --output text)
+          echo "blocking=$([[ "$REVIEW_STATUS" == "FAIL" ]] && echo true || echo false)" >> "$GITHUB_OUTPUT"
+
+      - name: Update commit status
+        if: always() && steps.codebuild.outputs.blocking != 'skip'
+        shell: bash
+        env:
+          GH_TOKEN: ${{ github.token }}
+          STATUS_URL: ${{ github.api_url }}/repos/${{ github.repository }}/statuses/${{ github.event.pull_request.head.sha }}
+          REPORT_URL: https://d28bfvmis1skm5.cloudfront.net/${{ github.event.repository.name }}/pr-${{ github.event.pull_request.number }}/${{ github.event.pull_request.head.sha }}.html
+          BLOCKING: ${{ steps.codebuild.outputs.blocking }}
+        run: |
+          STATE=$([[ "$BLOCKING" == "true" ]] && echo "failure" || echo "success")
+          curl -sS -X POST \
+            -H "Authorization: token ${GH_TOKEN}" \
+            "${STATUS_URL}" \
+            -d "{\"state\":\"${STATE}\",\"context\":\"security-review / report\",\"target_url\":\"${REPORT_URL}\"}"

.github/workflows/zig.yml

@@ -7,6 +7,10 @@ on:
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref_name }}
   cancel-in-progress: true
+
+permissions:
+  contents: read
+
 jobs:
   zig:
     if: github.repository_owner == 'aws'

CMakeLists.txt

@@ -5,7 +5,8 @@ cmake_policy(SET CMP0091 NEW)
 endif()
 
 set(SOFTWARE_NAME "awslc")
-set(SOFTWARE_VERSION "1.73.0")
+set(SOFTWARE_VERSION "5.0.0")
+set(AWSLC_FIPS_VERSION 4)
 set(ABI_VERSION 0)
 set(CRYPTO_LIB_NAME "crypto")
 set(SSL_LIB_NAME "ssl")
@@ -49,6 +50,13 @@ include(sources.cmake)
 include(TestBigEndian)
 include(CheckCCompilerFlag)
 
+message(STATUS "Versioning name:${SOFTWARE_NAME} version:${SOFTWARE_VERSION} abi:${ABI_VERSION}")
+if(BUILD_LIBSSL)
+  message(STATUS "Libraries crypto:${CRYPTO_LIB_NAME} ssl:${SSL_LIB_NAME}")
+else()
+  message(STATUS "Libraries crypto:${CRYPTO_LIB_NAME}")
+endif()
+
 macro(add_flag_if_supported VARIABLE FLAG)
   # Create a safe, unique variable name to cache the result of the check
   string(MAKE_C_IDENTIFIER "HAVE_C_FLAG_${FLAG}" _CHECK_VAR_NAME)

SANDBOXING.md

@@ -93,6 +93,12 @@ On Linux ARM platforms, BoringSSL depends on OS APIs to query CPU capabilities.
 work around bugs in older Android devices, may additionally read
 `/proc/cpuinfo`.
 
+On Linux targets whose libc does not provide `getauxval` (e.g. older uclibc),
+AWS-LC falls back to reading `/proc/self/auxv` directly. This applies to the
+ARM, AArch64, and PPC64LE CPU capability paths as well as the `urandom`
+entropy path's debug lookup. Sandbox policies should permit opening
+`/proc/self/auxv` on such targets.
+
 On 64-bit Apple ARM platforms, BoringSSL needs to query `hw.optional.*` sysctls.
 
 If querying CPU capabilities fails, BoringSSL will still function, but may not

VERSIONING.md

@@ -0,0 +1,143 @@
+# AWS-LC Versioning
+
+This document describes how AWS-LC is versioned and released, and how consumers should choose between the release types we offer.
+
+## Overview
+
+AWS-LC offers two release types:
+
+* **Rolling mainline releases** are the primary release for most consumers. Rolling mainline receives the latest features, performance improvements, and security fixes as they are developed.
+* **Long-term support (LTS) releases** are intended for consumers that require a stable ABI over a multi-year support window.
+
+Rolling mainline is periodically submitted for FIPS 140-3 validation, though changes may land between submissions. LTS branches are fixed FIPS submissions; they are not modified after they are cut, except for the backports permitted by the [LTS release policy](#lts-release-policy). The FIPS version number a given build corresponds to is tracked independently of the AWS-LC version number (see [FIPS version number](#fips-version-number)).
+
+AWS-LC is committed to providing a stable public API across both release types. LTS releases additionally guarantee ABI stability for the duration of the support window.
+
+## AWS-LC version numbers
+
+AWS-LC releases follow a `MAJOR.MINOR.PATCH` scheme. Mainline uses only major and minor; FIPS branches (LTS and non-LTS snapshot) use only minor and patch.
+
+* **Major** (`X.0.0`):
+  * Bumped on mainline when a new LTS branch is cut (see [LTS version evolution](#lts-version-evolution)).
+  * Signals that the previous major line now belongs to an LTS branch and mainline has moved to a new major line.
+* **Minor** (`X.Y.0`):
+  * The only increment used on mainline. Every mainline release bumps minor, regardless of the size or kind of change (features, security fixes, performance improvements, bug fixes, platform compatibility fixes, etc.).
+  * Also used on LTS branches for backwards compatible features that do not break API/ABI compatibility.
+* **Patch** (`X.Y.Z`):
+  * Used only on FIPS branches (LTS or non-LTS snapshot) for non-additive changes — security fixes, bug fixes, and platform compatibility fixes.
+  * Mainline never produces patch versions, so patch increments on FIPS branches cannot collide with mainline.
+
+AWS-LC version numbers do not follow Semantic Versioning. Major version bumps on mainline are tied to LTS branch cuts (see [LTS version evolution](#lts-version-evolution)) and do not necessarily indicate API or ABI breaking changes. Consumers needing to detect public API surface changes can use the `AWSLC_API_VERSION` macro defined in `openssl/base.h`, which increments when the API surface changes.
+
+A build's AWS-LC version can be queried at runtime via the `awslc_version_string` API:
+
+```c
+OPENSSL_EXPORT const char *awslc_version_string(void);
+```
+
+AWS-LC version numbers are independent of the FIPS version number. A bump in either does not imply a bump in the other. To identify the FIPS submission a build corresponds to, use `FIPS_version` (see [FIPS version number](#fips-version-number)).
+
+## FIPS version number
+
+The FIPS version number is an integer that identifies a specific FIPS validation submission. It is incremented each time a new FIPS branch is cut from mainline and corresponds to the value used in our submissions to the NIST Cryptographic Module Validation Program (CMVP). Mainline tracks the most recent FIPS version number that has been cut from it.
+
+The FIPS version number is decoupled from the AWS-LC version number. A build's FIPS version number can be queried at runtime via the `FIPS_version` API:
+
+```c
+OPENSSL_EXPORT uint32_t FIPS_version(void);
+```
+
+Prior to this scheme, AWS-LC version numbers and FIPS version numbers were coupled (for example, AWS-LC FIPS 3.0 corresponded to the third FIPS submission). That coupling has been removed. Earlier FIPS branches still carry version numbers matching their FIPS version number, and their FIPS version number is documented in the security policy published alongside each validation.
+
+## Release types
+
+### Rolling mainline
+
+Mainline is the primary release for AWS-LC consumers. It receives all new features, performance improvements, and security fixes as they are developed.
+
+Rolling mainline characteristics:
+
+* Latest features, performance improvements, and security fixes.
+* Submitted for FIPS validation approximately every 6 months.
+
+### LTS releases
+
+LTS releases are intended for consumers that require a stable ABI. An LTS branch is cut from mainline and then receives only the changes permitted by the [LTS release policy](#lts-release-policy).
+
+LTS release characteristics:
+
+* Cut from mainline every 2 years and supported for 5 years from the date the branch is cut.
+* Each LTS branch is submitted for FIPS validation.
+
+Both rolling mainline releases and LTS releases are tagged in the public repository; non-LTS FIPS branches are not.
+
+## LTS release policy
+
+### LTS version evolution
+
+Each LTS branch inherits mainline's major version at the time it is cut. In the next commit, mainline bumps to the next major version. This guarantees that mainline and every LTS branch have distinct major version numbers.
+
+For example, when mainline is at `4.13.0` and an LTS branch is cut, the `4.x` version prefix is reserved exclusively for the LTS branch. The `4.x` line receives only the changes permitted below, as patch (`4.13.1`, `4.13.2`, ...) or minor (`4.14.0`, `4.15.0`, ...) increments. Mainline advances to `5.0.0` and continues normal development with minor increments only (`5.1.0`, `5.2.0`, ...). Because mainline never returns to the `4.x` line, version numbers on the LTS cannot collide with mainline. When the next LTS is cut approximately two years later, it takes ownership of whatever major version line mainline is on at that moment, and mainline bumps again.
+
+### Permitted changes on LTS branches
+
+The following are permitted on LTS branches, mapped to version increments:
+
+* Minor increments:
+  * Additive changes that preserve existing function signatures.
+* Patch increments:
+  * Security fixes for CVEs and critical vulnerabilities. These may alter the FIPS module integrity hash when necessary.
+  * Bug fixes that do not alter public API behavior, ABI compatibility, or the FIPS module integrity hash.
+  * Platform compatibility fixes for supported operating environments that do not alter the FIPS module integrity hash.
+
+See [AWS-LC version numbers](#aws-lc-version-numbers) for the full scheme.
+
+### Not permitted on LTS branches
+
+The following are not permitted on LTS branches:
+
+* API or ABI breaking changes.
+* Changes within the FIPS module boundary that alter the integrity hash, unless required for a security fix.
+* New features or algorithms that alter the FIPS module.
+* Performance improvements that alter the FIPS module or change behavioral characteristics.
+
+### Support window
+
+Each LTS branch is supported for 5 years from the date the branch is cut. End of support (EOS) means security fixes and other changes are no longer backported to the branch. EOS applies regardless of the status of any FIPS certificate associated with the branch; once an LTS reaches EOS, consumers should migrate to mainline or to a newer LTS.
+
+At any given time, at least one LTS branch is within its support window. Consecutive LTS branches overlap so that consumers always have a supported migration target.
+
+## Non-LTS FIPS branches
+
+FIPS validation requires a fixed snapshot of the cryptographic module's source code. Each time AWS-LC is submitted for FIPS validation, a branch is cut from mainline that preserves the exact code submitted. Most of these branches are not designated as LTS. LTS designation is decided at branch-cut time; existing non-LTS branches are never promoted to LTS.
+
+Non-LTS FIPS branches exist solely to preserve the validated snapshot. They do not receive release tags, and consumers should not depend on them.
+
+We may apply critical security fixes to a non-LTS FIPS branch from the time it is cut until a newer FIPS branch (LTS or non-LTS) receives NIST certification and supersedes it. This is a maintenance concession; these branches are not supported for consumption. Once superseded, the previous non-LTS branch is frozen and receives no further updates.
+
+A non-LTS FIPS branch inherits its version from mainline at cut time and only ever issues patch-level increments (e.g., a branch cut at `5.6.0` becomes `5.6.1` after a security fix). Because mainline only produces minor increments (`5.6.0` → `5.7.0`), patch versions on a non-LTS branch cannot collide with mainline.
+
+At branch-cut time, the non-LTS branch and mainline are the same build; `awslc_version_string()` and `FIPS_version()` return identical values on both. They diverge afterward — mainline through its next minor release, the non-LTS branch through any patch-level security fixes.
+
+## Branch naming conventions
+
+Going forward, FIPS branches use a suffix to indicate their release type:
+
+* `fips-YYYY-MM-DD-lts` — LTS branch. Receives security fixes and other permitted changes throughout its support window.
+* `fips-YYYY-MM-DD-snapshot` — Non-LTS validation snapshot. Frozen once it is no longer the most recently NIST-certified FIPS branch.
+
+The date in the branch name corresponds to the date the branch was cut for FIPS submission. Branches cut before this convention was adopted retain their original names.
+
+## Deprecation of legacy FIPS branches
+
+`fips-2025-09-12-lts` (AWS-LC FIPS 4.x) is the first branch designated as LTS under this versioning scheme. It is supported for 5 years from its cut date (approximate EOS: September 2030).
+
+FIPS branches published before this scheme have the following deprecation timelines:
+
+| Branch            | End of support     |
+|-------------------|--------------------|
+| AWS-LC FIPS 1.0   | October 2026       |
+| AWS-LC FIPS 2.0   | April 2027         |
+| AWS-LC FIPS 3.0   | April 2028         |
+
+After a branch reaches end of support, security fixes will no longer be backported. Consumers on these branches should migrate to mainline or to the FIPS 4.x LTS branch before the listed date.

crypto/CMakeLists.txt

@@ -607,6 +607,15 @@ function(build_libcrypto)
   endif()
   if(WIN32)
     target_link_libraries(${arg_NAME} PUBLIC ws2_32)
+    # MinGW (non-Clang) builds target Windows 7 (see the top-level
+    # CMakeLists.txt, which adds -D_WIN32_WINNT=_WIN32_WINNT_WIN7), so
+    # `crypto/rand_extra/windows.c` compiles under the AWSLC_WINDOWS_7_COMPAT
+    # branch and calls BCryptGenRandom from bcrypt.dll. On MSVC this is
+    # handled by `#pragma comment(lib, "bcrypt.lib")` in that file, but
+    # MinGW ignores that pragma so we need to add the link explicitly.
+    if(MINGW)
+      target_link_libraries(${arg_NAME} PUBLIC bcrypt)
+    endif()
   endif()
 
   if(AWSLC_LINK_THREADS)

crypto/bio/bio.c

@@ -305,6 +305,9 @@ int BIO_write(BIO *bio, const void *in, int inl) {
 }
 
 int BIO_write_ex(BIO *bio, const void *data, size_t data_len, size_t *written_bytes) {
+  if (written_bytes != NULL) {
+    *written_bytes = 0;
+  }
   if (bio == NULL) {
     OPENSSL_PUT_ERROR(BIO, BIO_R_NULL_PARAMETER);
     return 0;
@@ -322,9 +325,6 @@ int BIO_write_ex(BIO *bio, const void *data, size_t data_len, size_t *written_by
     }
     return 1;
   } else {
-    if (written_bytes != NULL) {
-      *written_bytes = 0;
-    }
     return 0;
   }
 }

crypto/bio/bio_addr.c

@@ -151,7 +151,10 @@ int BIO_ADDR_rawaddress(const BIO_ADDR *ap, void *p, size_t *l) {
     return 0;
   }
   if (l != NULL) {
-    *l = len;
+    // AF_UNIX includes the trailing NUL written below so |*l| matches the
+    // bytes written to |p| and reflects sockaddr_un's NUL-terminated path.
+    // OpenSSL does not write this NUL; aws-lc intentionally does.
+    *l = (ap->sa.sa_family == AF_UNIX) ? len + 1 : len;
   }
 
   if (p != NULL) {