Skip to content

fix(a2a,config): give --connect its own client-side TLS/SSRF policy#5884

Merged
bug-ops merged 1 commit into
mainfrom
fix/5878-remote-tui-connect-tls
Jul 10, 2026
Merged

fix(a2a,config): give --connect its own client-side TLS/SSRF policy#5884
bug-ops merged 1 commit into
mainfrom
fix/5878-remote-tui-connect-tls

Conversation

@bug-ops

@bug-ops bug-ops commented Jul 10, 2026

Copy link
Copy Markdown
Owner

Summary

  • zeph --tui --connect <URL> failed against its own documented plain-http:// loopback usage example (--connect http://127.0.0.1:8080/a2a/stream) on a fresh/default config, because the client-side SecurityPolicy was built from config.a2a (A2aServerConfig, the daemon's own server settings), whose require_tls/ssrf_protection default to true.
  • Adds a dedicated [a2a_client] config section (A2aClientConfig, env vars ZEPH_A2A_CLIENT_REQUIRE_TLS/ZEPH_A2A_CLIENT_SSRF_PROTECTION) used only by the --connect client path; [a2a]/A2aServerConfig is left untouched for the daemon's own server.
  • Loopback targets (127.0.0.1, ::1, localhost, via a new zeph_common::net::is_loopback_host helper) always bypass TLS/SSRF checks automatically, no config changes required. Non-loopback targets still require HTTPS and SSRF validation by default, unchanged from before.
  • A2aServerConfig::require_tls/.ssrf_protection are now unread by any code path (were only ever read by the buggy client wiring); marked reserved/inert in place rather than removed, since removal is a breaking config change needing a --migrate-config step — tracked as a P3 follow-up.
  • Updated docs: book/src/advanced/a2a.md, book/src/reference/configuration.md, .zeph/skills/setup-guide/SKILL.md, config/default.toml, docker/docker-compose.yml + docker-compose.dev.yml, CHANGELOG.md, and the live-testing playbook/coverage-status at the main-repo .local/testing/ path.

Test plan

  • cargo +nightly fmt --check
  • cargo clippy --profile ci --workspace --all-targets --features "desktop,ide,server,chat,pdf,scheduler,testing" -- -D warnings
  • cargo nextest run --config-file .github/nextest.toml --workspace --features "desktop,ide,server,chat,pdf,scheduler" --lib --bins — 12481/12481 passed
  • RUSTFLAGS="-D warnings" RUSTDOCFLAGS="--deny rustdoc::broken_intra_doc_links" cargo doc --no-deps --workspace --features "desktop,ide,server,chat,pdf,scheduler"
  • New unit tests covering loopback IPv4/IPv6/hostname bypass, non-loopback hardened/permissive policy, unparseable-URL fail-safe, and edge cases (uppercase scheme, userinfo/port, 0.0.0.0, private non-loopback IPs, localhost-substring hostnames, IPv4-mapped IPv6 loopback documented as a known safe-direction gap)
  • Adversarial code review (2 rounds, both approved)

Closes #5878

@github-actions github-actions Bot added bug Something isn't working size/L Large PR (201-500 lines) documentation Improvements or additions to documentation rust Rust code changes core zeph-core crate config Configuration file changes labels Jul 10, 2026
@bug-ops
bug-ops enabled auto-merge (squash) July 10, 2026 16:46
zeph --tui --connect <URL> failed against its own documented plain-http://
loopback usage example on a fresh config. src/tui_remote.rs built the
client-side SecurityPolicy from config.a2a (A2aServerConfig, the daemon's
own server settings), whose require_tls/ssrf_protection default to true,
so every --connect http://... attempt was rejected before reaching the
daemon, even against loopback.

Add a dedicated [a2a_client] config section (A2aClientConfig, env vars
ZEPH_A2A_CLIENT_REQUIRE_TLS/ZEPH_A2A_CLIENT_SSRF_PROTECTION) used only by
the --connect path; [a2a] is left untouched for the daemon's own server.
Loopback targets (127.0.0.1, ::1, localhost) always bypass TLS/SSRF checks
via a new zeph_common::net::is_loopback_host helper; non-loopback targets
still require HTTPS and SSRF validation by default, unchanged from before.

A2aServerConfig::require_tls/.ssrf_protection are now unread by any code
path; marked reserved/inert in place rather than removed, since removal
would be a breaking config change needing a migration step.

Closes #5878
@bug-ops
bug-ops force-pushed the fix/5878-remote-tui-connect-tls branch from 1b48cc5 to eb63b2f Compare July 10, 2026 16:48
@bug-ops
bug-ops merged commit 62eabc6 into main Jul 10, 2026
47 checks passed
@bug-ops
bug-ops deleted the fix/5878-remote-tui-connect-tls branch July 10, 2026 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working config Configuration file changes core zeph-core crate documentation Improvements or additions to documentation rust Rust code changes size/L Large PR (201-500 lines)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

--connect <URL> remote TUI attach fails against its own documented http:// loopback example (require_tls defaults to true)

1 participant