ssl: remove aws-lc support

[ggreenway]

This was originally added to support ppc64, and was easier to add than OpenSSL support. Since then, OpenSSL support has been added, which also supports ppc64.

Removing aws-lc to simplify the set of possible configurations and maintenance.

[repokitteh-read-only]

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @jwendell

🐱

Caused by: #46023 was opened by ggreenway.

see: more, trace.

[ggreenway]

Does aws-lc provide anything of value now that we have OpenSSL support? If not we can remove some dependencies and build complications.

If there are good reasons to keep this, let's document them (and close this PR).

cc @Jenkins-J

[phlax]

i think there is an arm+fips case for aws-lc also - iirc from changes to it - not sure if that can be accomodated - but also not sure that ppcle is the only consumer

[ggreenway]

Claude says that openssl can do fips on ARM.

[jwendell]

AWS-LC in Envoy: Can it be dropped in favor of OpenSSL?

Envoy supports 3 SSL libraries (ignoring FIPS variants): BoringSSL, AWS-LC, and OpenSSL.
This document analyzes whether AWS-LC can be dropped in favor of OpenSSL to reduce maintenance burden.

Why AWS-LC was added

AWS-LC was introduced in commit 60aed1c0ae (Feb 2025) — "Build Envoy with aws_lc on Power (ppc64le)".
The motivation was FIPS compliance on ppc64le, since BoringSSL-FIPS only supports x86_64 and aarch64.

Conclusion: No, not without regression

Replacing AWS-LC with OpenSSL would cause several regressions:

Concern	AWS-LC	OpenSSL
FIPS on ppc64le	Compile-time FIPS (--config=aws-lc-fips)	Runtime-only FIPS; no --config=openssl-fips exists in Envoy
Linking	Static	Dynamic (dlopen, requires OpenSSL 3.5+ at runtime)
Cert compression (Brotli/Zlib)	Supported	Disabled (stubs)
Private key providers	Supported	Multiple tests disabled (BORINGSSL_TEST_P macro)
BoringSSL API compat	Near-native (AWS-LC is a BoringSSL fork, only needs thin aws_lc_compat.h)	Requires full bssl-compat shim layer in compat/openssl/
Security policy	Covered (though ppc64le itself is best-effort)	Explicitly not covered
HTTP/3	Disabled	Disabled (same)

The core blocker: FIPS

AWS-LC exists in Envoy primarily as a FIPS provider. It's the only way to get a compile-time
FIPS build on ppc64le (and serves as an alternative FIPS option on x86_64/aarch64 too). OpenSSL's
FIPS model is fundamentally different — runtime enforcement via OS configuration rather than a
validated build artifact.

Additional considerations

• AWS-LC is also used on x86_64 and aarch64 as an alternative FIPS option (not just ppc64le).
• The using_fips_ssl config setting group includes both BoringSSL-FIPS and AWS-LC — removing
  AWS-LC would reduce FIPS options.
• The README explicitly notes: "Builds for the ppc64le architecture or using aws-lc are not
  covered by the envoy security policy" — so it's already best-effort, but removing it entirely
  is a different story.

What would be needed to drop it

If the project wanted to pursue this, it would require:

1. Confirming no downstream users depend on AWS-LC FIPS (especially on ppc64le).
2. Building OpenSSL FIPS support into Envoy's build system (non-trivial).
3. Closing the feature gaps (cert compression, private key providers, static linking).
4. Getting buy-in from the ppc64le maintainers who contributed AWS-LC support.

Key files involved

• bazel/external/aws_lc.BUILD, aws_lc.genrule_cmd, aws_lc_build.bzl — AWS-LC build infrastructure
• bazel/repositories.bzl — repository definition with ppc64le-specific deps
• bazel/repository_locations.bzl — AWS-LC version (1.72.0 as of 2026-04-13)
• .bazelrc — --config=aws-lc-fips definition
• source/common/tls/aws_lc_compat.h — BoringSSL-to-AWS-LC API translation
• compat/openssl/ — full bssl-compat shim layer for OpenSSL
• bazel/SSL.md — SSL library configuration documentation

[ggreenway]

I don't think compile-time vs runtime FIPS is a big deal, as long as there's a way to make it work (which there is with OpenSSL).

One motivation for this is that the boringssl code may start using a new CREDENTIALS API, which I don't believe is supported in aws-lc or openssl. We have people committed to writing the openssl-compat code needed for boringssl changes, but I don't think there's anyone signed up for large changes to aws-lc, nor do we have code/infrastructure setup to support it. So one way out of that is to drop aws-lc entirely.

[phlax]

totally agree

can we switch ci on properly for openssl?

its no slower or more error prone than other parts, and its well supported

[phlax]

... as a step towards it being officially supported i guess

[ggreenway]

I don't think we need to couple these two concerns (removing aws-lc, vs level of support for openssl).

In terms of timing, I don't think there's any reason to rush this, so I'd say let's wait until after the upcoming release if we decide to move forward with this PR.