openai / openai/codex

Codex app-server panics on iSH when the aws-lc provider lacks ECDSA P-521

Open
#39,186 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app-server bug
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

Summary

codex-app-server terminates during startup on an iSH-based ARM64 embedded Linux runtime when the successfully installed aws-lc rustls provider exposes a reduced signature-verification algorithm set that does not contain ECDSA_NISTP521_SHA512.

Environment

  • Codex source: rust-v0.147.0
  • binary target: aarch64-unknown-linux-musl
  • runtime: iSH ARM64 embedded in an iOS app
  • device: iPhone

Reproduction

  1. Build codex-app-server for aarch64-unknown-linux-musl from rust-v0.147.0.
  2. Launch the binary in the iSH ARM64 runtime.
  3. Initialize app-server so it installs the process-wide rustls crypto provider.

Actual behavior

Provider installation succeeds, but app-server exits before it can initialize or make a TLS request:

installed rustls crypto provider must support ECDSA_NISTP521_SHA512

Expected behavior

Keep the successfully installed provider and allow app-server to start. If a later TLS connection actually requires an unsupported certificate signature scheme, rustls/WebPKI should reject that connection normally.

Root cause analysis

ensure_rustls_crypto_provider() installs rustls::crypto::aws_lc_rs::default_provider(), then unconditionally asserts that the installed provider advertises ECDSA_NISTP521_SHA512.

That converts a certificate-specific capability into a process-wide startup requirement. It is also stricter than the existing behavior for a provider installed before Codex starts: that provider is preserved without requiring P-521.

Proposed fix

  • remove the post-install process-terminating P-521 assertion
  • keep the successfully installed platform-provided aws-lc algorithm set
  • update the provider integration test to verify that the installed schemes equal the schemes available from that platform's aws-lc provider
  • retain fail-closed TLS verification for certificates that use unsupported schemes

Reference implementation:

Validation

  • just fmt
  • just test -p codex-utils-rustls-provider — 2 tests passed
  • Codex CR completed with no P1/P2 findings
  • the same source change was rebuilt for aarch64-unknown-linux-musl and exercised in the iSH ARM64 runtime on iPhone
  • patched app-server initialized and completed an HTTPS Responses request; the unmodified release binary reproduced the startup assertion

This does not expand certificate trust: rustls/WebPKI continues to reject certificates whose signature scheme is unsupported by the installed provider.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at ensure_rustls_crypto_provider() and the provider integration tests in codex-utils-rustls-provider. Run just test -p codex-utils-rustls-provider after removing the startup requirement for ECDSA_NISTP521_SHA512 and update the test to compare installed schemes with the platform aws-lc provider. Done means reduced providers remain installed, the tests pass, and unsupported certificate schemes still fail during TLS verification.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, security
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.