You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix email feature: config loading, flag forwarding, IPC rename
pilotctl daemon start was not reading email from config.json and
not forwarding --email to the daemon subprocess, making v1.4.0
unusable for the mandatory email flow.
Changes:
- Fix pilotctl to read email from config.json and forward --email flag
- Rename DaemonInfo.Owner to Email, IPC key owner→email
- Add --email to install.sh (LaunchAgent, systemd, config, prompts)
- Rename -owner to -email across all docs, examples, blog posts
- Update tests for Email field rename
Copy file name to clipboardExpand all lines: docs/WHITEPAPER.tex
+7-7Lines changed: 7 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -244,7 +244,7 @@ \subsection{Registry}
244
244
\item\textbf{Heartbeats.} Nodes ping the Registry periodically to confirm liveness.
245
245
\end{itemize}
246
246
247
-
\textbf{Persistence.} The Registry supports atomic JSON snapshots (\texttt{-store path/to/registry.json}). Every state mutation---node registration, network creation, network join, deregistration, stale-node reaping---triggers a save. The snapshot captures all nodes, networks, membership lists, public keys, owner bindings, trust pairs, and ID counters. On restart, the Registry loads the snapshot and resumes operation with all state intact. Writes use a temporary file with \texttt{os.Rename} for crash safety---the store file is never partially written.
247
+
\textbf{Persistence.} The Registry supports atomic JSON snapshots (\texttt{-store path/to/registry.json}). Every state mutation---node registration, network creation, network join, deregistration, stale-node reaping---triggers a save. The snapshot captures all nodes, networks, membership lists, public keys, email bindings, trust pairs, and ID counters. On restart, the Registry loads the snapshot and resumes operation with all state intact. Writes use a temporary file with \texttt{os.Rename} for crash safety---the store file is never partially written.
248
248
249
249
\textbf{TLS.} The Registry supports TLS transport (\texttt{-tls-cert}, \texttt{-tls-key}). When configured, all control-plane traffic---registrations, lookups, heartbeats---is encrypted in transit.
250
250
@@ -274,7 +274,7 @@ \subsection{Daemon}
274
274
\begin{enumerate}
275
275
\item Discovers its public endpoint via the Beacon
\item Registers with the Registry, receiving a virtual address (or reclaiming an existing one via identity or owner)
277
+
\item Registers with the Registry, receiving a virtual address (or reclaiming an existing one via identity or email)
278
278
\item Generates an ephemeral X25519 keypair for tunnel encryption (enabled by default)
279
279
\item Opens a Unix domain socket (mode 0600) for local drivers to connect
280
280
\item Starts the trust handshake service on port~444 (if identity available)
@@ -456,18 +456,18 @@ \subsection{pilotctl}
456
456
pilotctl lookup 3
457
457
pilotctl deregister
458
458
459
-
# Key rotation via signature or owner recovery
459
+
# Key rotation via signature or email recovery
460
460
pilotctl rotate-key 3 agent-a@pilot
461
461
\end{lstlisting}
462
462
463
-
The \texttt{info} command provides a comprehensive view of daemon state, including identity status (ephemeral vs.\ persistent Ed25519), owner binding, encryption mode, authenticated peer count, and per-connection statistics (bytes, segments, retransmissions, SACK blocks, duplicate ACKs, congestion window, in-flight data, SRTT, RTTVAR, and recovery status). The \texttt{peers} command shows each peer's real endpoint, whether the tunnel is encrypted, and whether the key exchange was authenticated with Ed25519 signatures.
463
+
The \texttt{info} command provides a comprehensive view of daemon state, including identity status (ephemeral vs.\ persistent Ed25519), email binding, encryption mode, authenticated peer count, and per-connection statistics (bytes, segments, retransmissions, SACK blocks, duplicate ACKs, congestion window, in-flight data, SRTT, RTTVAR, and recovery status). The \texttt{peers} command shows each peer's real endpoint, whether the tunnel is encrypted, and whether the key exchange was authenticated with Ed25519 signatures.
\textbf{Identity.} Each node receives an Ed25519 keypair from the Registry upon registration. The private key is the node's identity token. The Registry holds all public keys and can verify identity. Identities can be persisted to disk (\texttt{-identity path/to/identity.json}) so that a node retains its keypair and virtual address across daemon restarts. On restart, the daemon re-registers with the stored public key and the registry recognizes the node, preserving its address and network memberships.
469
469
470
-
\textbf{Owner binding and key rotation.} Nodes can be bound to an owner identifier (typically an email) via the \texttt{-owner} flag. This enables key rotation recovery: if a node's private key is compromised or lost, the owner can request a new keypair from the registry. Key rotation supports two authentication paths: (1)~signature-based, where the node signs a challenge (\texttt{rotate:<node\_id>}) with its current Ed25519 private key, proving possession; or (2)~owner-based, where the owner identifier is matched against the registry's records. After rotation, the registry issues a fresh Ed25519 keypair while preserving the node's ID and network memberships. Owner binding also enables reclaiming a deregistered node's identity---re-registering with the same owner email recovers the original node~ID.
470
+
\textbf{Email binding and key rotation.} Nodes can be bound to an email address via the \texttt{-email} flag. This enables key rotation recovery: if a node's private key is compromised or lost, the email holder can request a new keypair from the registry. Key rotation supports two authentication paths: (1)~signature-based, where the node signs a challenge (\texttt{rotate:<node\_id>}) with its current Ed25519 private key, proving possession; or (2)~email-based, where the email address is matched against the registry's records. After rotation, the registry issues a fresh Ed25519 keypair while preserving the node's ID and network memberships. Email binding also enables reclaiming a deregistered node's identity---re-registering with the same email recovers the original node~ID.
471
471
472
472
\textbf{Trust boundaries.} Network membership is the trust boundary. Joining a network requires satisfying its rules (open enrollment, token verification, or member invitation). Once inside a network, communication is unrestricted. This is a deliberate design choice: complex per-connection ACLs are replaced by simple group membership.
473
473
@@ -779,8 +779,8 @@ \subsection{Summary}
779
779
Nagle coalescing & Local & Pass (100 writes in 4\,ms) \\
Copy file name to clipboardExpand all lines: docs/enterprise-readiness-report.tex
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -132,11 +132,11 @@ \subsection{Identity}
132
132
133
133
\textbf{Signed mutations.} All registry write operations routed through the daemon (set-hostname, set-visibility, deregister) are signed with the node's Ed25519 private key. The registry verifies signatures before applying mutations, preventing spoofed requests.
134
134
135
-
\textbf{Key rotation.} The \texttt{rotate\_key} command supports two authentication paths: signature-based (proving possession of the current key) and owner-based (matching an email identifier). After rotation, the registry issues a fresh keypair while preserving the node's ID and network memberships.
135
+
\textbf{Key rotation.} The \texttt{rotate\_key} command supports two authentication paths: signature-based (proving possession of the current key) and email-based (matching the registered email address). After rotation, the registry issues a fresh keypair while preserving the node's ID and network memberships.
136
136
137
137
\textbf{TLS cert pinning.} The registry client supports TLS with certificate pinning (\texttt{DialTLSPinned}), preventing man-in-the-middle attacks on the control plane.
138
138
139
-
\textbf{Owner binding.} Nodes can be bound to an owner identifier (typically an email) via the \texttt{-owner} flag. This enables key recovery and re-registration after deregistration.
139
+
\textbf{Email binding.} Nodes can be bound to an email address via the \texttt{-email} flag. This enables key recovery and re-registration after deregistration.
140
140
141
141
\textbf{Authenticated key exchange.} When a daemon has a persisted Ed25519 identity, the tunnel key exchange is upgraded from anonymous (\texttt{PILK}) to authenticated (\texttt{PILA}). The signature proves the X25519 ephemeral key belongs to the claimed identity, preventing man-in-the-middle substitution.
142
142
@@ -203,7 +203,7 @@ \subsection{Identity Gaps}
203
203
No identity expiry or forced rotation & Medium & Compromised keys live forever \\
204
204
No workload attestation & Medium & Cannot verify \emph{what} a process is \\
205
205
No trust domain concept & Medium & No federation boundary \\
206
-
Owner field is unverified & Low & Email is informational only \\
206
+
Email field is unverified & Low & Email is informational only \\
0 commit comments