[PR #317] [MERGED] fix(cli): install a rustls crypto provider so aenv build works over HTTPS #344

New issue

Closed

opened 2026-10-29 14:22:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:22:26 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/AgentENV/pull/317
Author: @nblintao
Created: 9/23/2026
Status: ✅ Merged
Merged: 9/24/2026
Merged by: @yingdi-shan

Base: main ← Head: fix/aenv-rustls-provider

📝 Commits (1)

e4e87c7 fix(cli): install a rustls crypto provider so aenv build works over HTTPS

📊 Changes

4 files changed (+30 additions, -0 deletions)

View changed files

📝 Cargo.lock (+1 -0)
📝 crates/aenv/Cargo.toml (+1 -0)
📝 crates/aenv/src/client/buildkit.rs (+18 -0)
📝 crates/aenv/src/main.rs (+10 -0)

📄 Description

What

aenv installs rustls's aws-lc-rs provider as the process-level default at startup.

Why

With an https:// API URL, aenv build panics as soon as it opens the BuildKit tunnel:

Building image...
thread 'main' panicked at .../rustls-0.23.37/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.

The CLI's dependencies compile in both of rustls's providers: reqwest's rustls feature enables aws-lc-rs, and ureq's tls feature enables ring. reqwest and ureq each configure their provider explicitly, so ordinary HTTPS requests work. tokio-tungstenite's TLS connector uses the process-level default instead, and rustls cannot choose one when both providers are present, so the first wss:// connection panics. buildkit_tunnel maps an https API URL to wss, so every aenv build against an HTTPS endpoint hits this; an http URL maps to ws and is unaffected.

Reproduced with the v0.2.2 release binary (aenv-darwin-aarch64) against an HTTPS endpoint, and on Linux by the new unit test (see Validation).

None filed; the panic and its cause are above.

Scope and non-goals

Only the choice of provider. aws-lc-rs is the provider reqwest already uses. The duplicate provider is left in place; removing ring would mean changing ureq's TLS setup, which is a larger change than this fix needs.

Design and behavior changes

install_crypto_provider() is the first thing main runs. install_default fails only when a provider is already installed, which serves equally well, so its result is ignored.

Compatibility and operations

Public API or generated protocol: none.
Configuration or defaults: none.
Snapshot manifest, artifact layout, or storage format: none.
Upgrade and rollback: none; the change is confined to the CLI.
Host requirements, permissions, ports, or dependencies: rustls becomes a direct dependency of aenv, at the 0.23.37 already in Cargo.lock; no new crates.

Validation

make fmt
make clippy
make test-unit
Relevant Rust integration tests
make -C services test (required when services/ changes)
Generated clients/server regenerated with the documented make target
Documentation updated
Benchmarks or performance comparison completed

Commands and results:

This PR's CI passes: fmt, clippy, unit-tests, agentenv-tests, envd-tests, ublk-tests, and both e2e-tests jobs (single-node and docker-compose). The new test opens a wss:// connection to a local listener that accepts and hangs up, so the client gets as far as setting up TLS:

test client::buildkit::tests::wss_connection_fails_instead_of_panicking ... ok

With the provider line removed, the same test fails with the panic above:

test client::buildkit::tests::wss_connection_fails_instead_of_panicking ... FAILED
---- client::buildkit::tests::wss_connection_fails_instead_of_panicking stdout ----
thread 'client::buildkit::tests::wss_connection_fails_instead_of_panicking' panicked at .../rustls-0.23.37/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.

Skipped checks and reasons: an end-to-end aenv build against an HTTPS endpoint with a binary built from this branch was not run; the unit test covers the connection setup that panicked.

Risks and reviewer notes

Low. The change is crates/aenv/src/main.rs; the test is in crates/aenv/src/client/buildkit.rs.

Checklist

The PR contains one coherent change and no unrelated formatting or refactoring.
New behavior is covered by tests, or I explained why testing is impractical.
Logs and examples contain no credentials, tokens, or private registry information.
I did not manually edit generated code without updating its source and regenerating it.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/AgentENV/pull/317 **Author:** [@nblintao](https://github.com/nblintao) **Created:** 9/23/2026 **Status:** ✅ Merged **Merged:** 9/24/2026 **Merged by:** [@yingdi-shan](https://github.com/yingdi-shan) **Base:** `main` ← **Head:** `fix/aenv-rustls-provider` --- ### 📝 Commits (1) - [`e4e87c7`](https://github.com/kvcache-ai/AgentENV/commit/e4e87c772735ce99a0b6ba17d0184e99fd104402) fix(cli): install a rustls crypto provider so aenv build works over HTTPS ### 📊 Changes **4 files changed** (+30 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+1 -0) 📝 `crates/aenv/Cargo.toml` (+1 -0) 📝 `crates/aenv/src/client/buildkit.rs` (+18 -0) 📝 `crates/aenv/src/main.rs` (+10 -0) </details> ### 📄 Description ## What `aenv` installs rustls's aws-lc-rs provider as the process-level default at startup. ## Why With an `https://` API URL, `aenv build` panics as soon as it opens the BuildKit tunnel: ```text Building image... thread 'main' panicked at .../rustls-0.23.37/src/crypto/mod.rs:249:14: Could not automatically determine the process-level CryptoProvider from Rustls crate features. Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled. ``` The CLI's dependencies compile in both of rustls's providers: reqwest's `rustls` feature enables aws-lc-rs, and ureq's `tls` feature enables ring. reqwest and ureq each configure their provider explicitly, so ordinary HTTPS requests work. tokio-tungstenite's TLS connector uses the process-level default instead, and rustls cannot choose one when both providers are present, so the first `wss://` connection panics. `buildkit_tunnel` maps an `https` API URL to `wss`, so every `aenv build` against an HTTPS endpoint hits this; an `http` URL maps to `ws` and is unaffected. Reproduced with the v0.2.2 release binary (`aenv-darwin-aarch64`) against an HTTPS endpoint, and on Linux by the new unit test (see Validation). ## Related issue None filed; the panic and its cause are above. ## Scope and non-goals Only the choice of provider. aws-lc-rs is the provider reqwest already uses. The duplicate provider is left in place; removing ring would mean changing ureq's TLS setup, which is a larger change than this fix needs. ## Design and behavior changes `install_crypto_provider()` is the first thing `main` runs. `install_default` fails only when a provider is already installed, which serves equally well, so its result is ignored. ## Compatibility and operations - Public API or generated protocol: none. - Configuration or defaults: none. - Snapshot manifest, artifact layout, or storage format: none. - Upgrade and rollback: none; the change is confined to the CLI. - Host requirements, permissions, ports, or dependencies: `rustls` becomes a direct dependency of `aenv`, at the 0.23.37 already in `Cargo.lock`; no new crates. ## Validation - [x] `make fmt` - [x] `make clippy` - [x] `make test-unit` - [x] Relevant Rust integration tests - [ ] `make -C services test` (required when `services/` changes) - [ ] Generated clients/server regenerated with the documented `make` target - [ ] Documentation updated - [ ] Benchmarks or performance comparison completed Commands and results: This PR's CI passes: fmt, clippy, unit-tests, agentenv-tests, envd-tests, ublk-tests, and both e2e-tests jobs (single-node and docker-compose). The new test opens a `wss://` connection to a local listener that accepts and hangs up, so the client gets as far as setting up TLS: ```text test client::buildkit::tests::wss_connection_fails_instead_of_panicking ... ok ``` With the provider line removed, the same test fails with the panic above: ```text test client::buildkit::tests::wss_connection_fails_instead_of_panicking ... FAILED ---- client::buildkit::tests::wss_connection_fails_instead_of_panicking stdout ---- thread 'client::buildkit::tests::wss_connection_fails_instead_of_panicking' panicked at .../rustls-0.23.37/src/crypto/mod.rs:249:14: Could not automatically determine the process-level CryptoProvider from Rustls crate features. Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled. ``` Skipped checks and reasons: an end-to-end `aenv build` against an HTTPS endpoint with a binary built from this branch was not run; the unit test covers the connection setup that panicked. ## Risks and reviewer notes Low. The change is `crates/aenv/src/main.rs`; the test is in `crates/aenv/src/client/buildkit.rs`. ## Checklist - [x] The PR contains one coherent change and no unrelated formatting or refactoring. - [x] New behavior is covered by tests, or I explained why testing is impractical. - [x] Logs and examples contain no credentials, tokens, or private registry information. - [x] I did not manually edit generated code without updating its source and regenerating it. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-29 14:22:26 +00:00