malsamiri-oai d5a8117e08 Use aws-lc-rs for rustls crypto provider (#27706) ...

## Why

Some enterprise TLS proxies issue certificate chains signed with
`ecdsa_secp521r1_sha512` / `ECDSA_NISTP521_SHA512`. Custom CA
configuration such as `SSL_CERT_FILE` can add the right trust root, but
it cannot make `rustls`'s `ring` verifier support a certificate
signature algorithm it does not advertise.

That can still break TLS after the CA bundle is configured, including on
Rust websocket paths that call the shared
`ensure_rustls_crypto_provider()` helper, such as the Responses
websocket connector and remote app-server client:

-
[`codex-api/src/endpoint/responses_websocket.rs`](eddc5c75ed/codex-rs/codex-api/src/endpoint/responses_websocket.rs (L441))
-
[`app-server-client/src/remote.rs`](eddc5c75ed/codex-rs/app-server-client/src/remote.rs (L718))

The `aws-lc-rs` `rustls` provider supports this P-521/SHA-512
certificate signature scheme, so use it as Codex's process-wide `rustls`
provider.

## What Changed

- Switch the workspace `rustls` feature from `ring` to `aws_lc_rs`.
- Update `codex-utils-rustls-provider` to install
`rustls::crypto::aws_lc_rs::default_provider()`.
- Add an assertion and integration test that the installed provider
supports `ECDSA_NISTP521_SHA512`.

## Verification

```shell
just fmt
just test -p codex-utils-rustls-provider
just bazel-lock-update
just bazel-lock-check
```

2026-06-15 11:32:13 -07:00

..

src

Use aws-lc-rs for rustls crypto provider (#27706)

2026-06-15 11:32:13 -07:00

tests

Use aws-lc-rs for rustls crypto provider (#27706)

2026-06-15 11:32:13 -07:00

BUILD.bazel

…

Cargo.toml

…