chore: run coder connect networking from launchdaemon

[ethanndickson]

Continues to address #201.

This PR reworks all XPC connections, such that the networking code runs within the privileged helper, instead of the network extension.

The XPC interfaces are described in XPC.swift, and roughly follow this sequence diagram:
(One difference is that we don't posix spawn the tunnel in this PR)

sequenceDiagram
    note left of App: User requests to start VPN:
    App->>+NetExt: Start VPN
    NetExt->>+PrivHelper: Request start VPN with TUN FD
    note right of PrivHelper: Privileged helper downloads and verifies binary.
    PrivHelper->>Tunnel: posix_spawn child process with FDs
    PrivHelper->>+Tunnel: Send proto start request
    Tunnel-->>-PrivHelper: Send proto start response
    PrivHelper->>+NetExt: Request for network config change
    NetExt-->>-PrivHelper: Response for network config change
    PrivHelper-->>-NetExt: Start VPN respons
    NetExt-->>-App: VPN started
    App->>PrivHelper: Request peer state
    PrivHelper->>Tunnel: Request peer state
    Tunnel-->>PrivHelper: Peer state response
    PrivHelper-->>App: Peer state response

    note left of App: Tunnel updates (bypass NetExt):
    Tunnel->>PrivHelper: Tunnel update proto message
    PrivHelper->>App: Tunnel update proto message

    note left of App: User requests to stop VPN:
    App->>+NetExt: Stop VPN
    NetExt->>+PrivHelper: Request stop VPN
    PrivHelper->>+Tunnel: Request stop VPN
    Tunnel-->>-PrivHelper: Stop VPN response
    note right of Tunnel: Tunnel binary exits
    PrivHelper-->>-NetExt: Stop VPN response
    NetExt-->>-App: VPN stopped

Loading

Of note is that the network extension starts and stops the daemon running within the privileged helper.
This is to support starting and stopping the VPN from the toggle in System Settings, and to ensure the "Connecting" and "Disconnecting" phase of the system VPN is indicative of the time the VPN is actually setting itself up and tearing itself down.

To accomplish this, the privileged helper listens on two different service names. One is connected to by the app, the other the network extension. (Once an XPC listener is connected to, communication is bidirectional)

[ethanndickson]

• fix: add code signing requirements to xpc connections #206 : 2 dependent PRs (#209 , #210 )
• chore: run coder connect networking from launchdaemon #203 👈 (View in Graphite)
• chore: make helper launchdaemon approval mandatory #205
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[ethanndickson]

Important to note that I've refactored all the XPC connections to use this pattern. With this, you're guaranteed that either the the XPC reply will be run (proxy.ping { reply } in this case) or the [...]WithErrorHandler callback.

[ethanndickson]

Temporary. I've put it in /var/root/Library/Application\ Support/com.coder.Coder-Desktop/ as part of the PR that downloads the slim binary.

[deansheather]

The XPC code seems a lot nicer but the type names and directions of the XPC types are hard to understand

[ethanndickson]

The class is called HelperXPCClient, but you can't have multiple Swift files with the same name. So, I've prepended NE, since this is the HelperXPCClient that runs within the network extension.

[Copilot]

Pull Request Overview

This PR reworks the XPC architecture to move VPN networking functionality from the network extension to a privileged helper daemon. The helper now manages the VPN tunnel and communicates with both the GUI app and network extension via separate XPC interfaces, implementing a more secure and maintainable design.

Key changes:

• Moved VPN networking code from network extension to privileged helper daemon
• Established bidirectional XPC communication between helper, app, and network extension
• Updated project configuration to support the new architecture

Reviewed Changes

Copilot reviewed 18 out of 20 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
project.yml	Updated build configuration to support helper dependencies and framework loading
XPC.swift	Defined new XPC interfaces for helper-app and helper-network extension communication
Download.swift	Renamed SignatureValidator class to Validator
main.swift	Simplified network extension entry point, removed XPC listener setup
PacketTunnelProvider.swift	Refactored to delegate VPN operations to helper via XPC
NEHelperXPCClient.swift	New XPC client for network extension to communicate with helper
Manager.swift	Moved to helper, updated to work without direct PacketTunnelProvider dependency
HelperXPCListeners.swift	New XPC server implementations for helper to handle app and network extension connections
AppHelperXPCClient.swift	New XPC client for GUI app to communicate with helper

[ethanndickson]

Merge activity

• Aug 6, 3:39 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Aug 6, 3:43 AM UTC: Graphite rebased this pull request as part of a merge.
• Aug 6, 3:44 AM UTC: @ethanndickson merged this pull request with Graphite.