feat(node): marketplace node daemon — config, credentials, control auth, inventory

[v0l]

First slice of marketplace increment 2. Scope is deliberately everything the daemon can do before a tunnel or a server-side endpoint exists, so nothing here is verified against a stub.

Control plane: LNVPS dials the node, over HTTP

Commands are request/response with a result to report — start a VM, stop a VM — which is what HTTP already is. A persistent websocket would mean rebuilding correlation ids, in-flight replay and reconnect semantics to arrive back at the same thing.

The usual reason to prefer an outbound socket is NAT traversal, and it does not apply here: once WireGuard is up LNVPS can reach the node directly, and a node without a working tunnel cannot serve guests anyway. This also matches lnvps_fw, so there is one daemon operational model rather than two.

Outbound calls remain for the two things that precede or outlive the tunnel: registration and heartbeat.

Auth is a pinned public key, not a bearer token

A shared token has to be generated, delivered to the node, stored on the operator's disk, rotated and revoked — five chances to leak a secret that grants control of every guest on the machine. A public key is not a secret, so none of those steps exist, and forging a command requires LNVPS's private key.

LNVPS_CONTROL_PUBKEY is compiled in; every command carries a NIP-98 event signed by the matching key. Verification binds:

Bound	Why
Signature	Nothing else in the event means anything until it is authentic
Pubkey	The operator owns the machine and can sign anything — but not as LNVPS
URL + method	A signed status poll must not be redirected at a destructive command
Body hash (payload)	Otherwise a captured header is reusable with different arguments
Timestamp ±60s	A captured request stops working quickly, with room for clock skew on a machine we do not administer
Replay cache	Replaying a captured stop is a second outage

A binary built without the key refuses to serve the control API rather than serving it to everyone.

HTTPS with the certificate pinned at registration

NIP-98 authenticates requests to the node. Nothing authenticated the node's replies — so anything able to answer on the tunnel address (a guest on the same machine that grabbed the IP, a route-server misconfiguration) could report that a VM started when it did not, or return another node's state.

The node self-signs, LNVPS records the SHA-256 fingerprint at registration, and every later call checks the presented certificate against that pin. No CA: a public CA would add a third party able to issue for a name we already control out-of-band.

Two consequences follow from the pin being registered once, and both are enforced rather than documented:

• The identity is persisted. A certificate minted per restart would stop matching the pin and the node would silently go unreachable.
• A corrupt certificate is a hard failure, not a reason to mint a new one — and the error says what to do. Regenerating quietly would change the fingerprint with nothing in the logs explaining the outage.

lnvps-node fingerprint prints the value to register, warning on stderr when it had to generate one, since that means LNVPS's copy is stale.

Verified against an independent implementation, because a SHA-256 agreeing with itself proves nothing:

lnvps-node:  848d7b290589dde8424f9e2409e0b51089c3b5dd6255def9d4d1bc8a7587da9c
openssl:     848d7b290589dde8424f9e2409e0b51089c3b5dd6255def9d4d1bc8a7587da9c

The tunnel is not by itself a trust boundary

Guests run on this machine, and a guest able to route to the node's tunnel address could otherwise stop its neighbours. Two independent defences, both required: the listener binds only the tunnel interface address — enforced at startup, not documented, because a comment in a config file does not survive being copied between machines — and every request is authenticated regardless.

lnvps_host_util becomes lib + bin

So the daemon and the lnvps-host-info pre-flight check an operator runs by hand cannot disagree about the same machine.

Its feature flags turned out to be decorative: vaapi and nvml existed in Cargo.toml, but the code gated on target_os instead, so --no-default-features did not compile — exactly the configuration a node needs, since a node has neither libva nor NVML installed. Now gated properly, and "we did not look" reports Unsupported rather than an empty feature list, which is a different answer from "we looked and found nothing".

Output is byte-identical to the pre-refactor binary, verified by building master with only the cfg fix applied and diffing.

The crate stays outside the workspace (its own lockfile and Docker context are unchanged); it is now in exclude, which is what makes the path dependency legal.

Verification

All seventeen guards were mutation-tested — each disabled individually, confirming at least one test fails:

drop pinned-pubkey check          caught ✓    drop wildcard-bind refusal          caught ✓
drop payload/body binding         caught ✓    drop tunnel-only bind check         caught ✓
drop replay guard                 caught ✓    drop credential permission check    caught ✓
drop timestamp window             caught ✓    drop signature verification         caught ✓
drop event-kind check             caught ✓    drop url binding                    caught ✓
drop method binding               caught ✓    silently regenerate a corrupt cert  caught ✓
mint a new cert per restart       caught ✓    world-readable private key          caught ✓
world-readable tls directory      caught ✓    claim a reload is newly generated   caught ✓
omit tunnel address from the SAN  caught ✓

Inventory parsers take &str/fixture trees rather than reading the host, so they are tested against captured contents rather than whatever the CI machine happens to have. Cross-checked against a real host anyway:

• 65178272 kB MemTotal → 66742550528 bytes (the kB label is KiB; reporting it unconverted would understate the machine 1024x)
• of 15 /sys/block entries — 8 loop devices, an optical drive, 4 empty card-reader slots at 0 sectors, 2 NVMe — exactly the 2 NVMe are reported. Both filters do real work on that machine.

Not in this PR

The listener itself, heartbeat frames, .deb packaging and GPU inventory. The listener needs a tunnel address to bind and a VmBackend to call; GPU inventory lands with increment 11a's eligibility probe so PCI address, IOMMU group cleanliness and BAR sizes are collected once, against real hardware.

Release requirement: the packaging workflow must inject LNVPS_CONTROL_PUBKEY, or released nodes will refuse control requests. Recorded in the plan as part of decision 12.

Increment 3 requirement: registration must carry the TLS fingerprint and store it on marketplace_node, with a re-registration path for rotation — a node that regenerates its certificate with no way to update the pin becomes permanently unreachable. Recorded as decision 14.