wireguard-admin/docs/evidence/milestone-16.md

Milestone 16 evidence: private systemd peer transport

Recorded 2026-10-27T22:42:48+02:00 on the native x86_64-unknown-linux-gnu development host. This is implementation and synthetic evidence, not systemd acceptance. The milestone remains blocked on private-peer behavioral and disposable-VM checks.

Source and protocol basis

The existing adapter connected only with zbus::Connection::system(). That cannot reach systemd where no system D-Bus daemon exists. Official systemd source shows root systemctl connecting to unix:path=/run/systemd/private and checking peer credentials. Its manual calls this an internal interface; compatibility across systemd releases is not guaranteed. Pinned zbus 5.19.0 provides p2p and EXTERNAL-authentication support.

The adapter now selects the system bus first and falls back to the private socket only for a missing/refused/disconnected bus endpoint during connection setup, before any restart request. Permission, handshake and timeout failures do not trigger fallback. The private path checks peer UID 0; method calls omit the bus destination; its JobRemoved stream uses a local peer match without org.freedesktop.DBus owner monitoring. The system-bus path retains its destination and owner-change watch. Both preserve Subscribe before RestartUnit, canonical unit identity, the shared deadline, job matching and conservative submission uncertainty. No retry follows a possibly submitted restart. Application backup/confirmation/runtime/applied logic is unchanged.

Checks, review, and gap

An independent GPT-6-Luna/high reviewer found M16-R1 (P2): private socket permission errors were reduced to RequestFailed. A separate GPT-6-Luna/high repairer changed the production builder error mapping to preserve PermissionDenied and added a focused synthetic assertion. The reviewer rechecked and closed R1. M16-R2 (P2) remains open: synthetic tests do not execute the production private peer branch end to end. An attempted local zbus UnixStream peer fixture failed at peer credential access with EPERM in the sandbox; later fixture variants did not establish a successful protocol path. Those experiments were removed from the test tree. They are not evidence that real systemd rejects the implementation. No host private socket was accessed.

Pinned rustc/Cargo 1.97.1, rustfmt 1.9.0, and Clippy 0.1.97 were verified. On the repaired inputs, from the repository root:

• cargo test --locked --lib service::dbus::tests -- --test-threads=1: 16 passed.
• cargo fmt --all -- --check: exit 0.
• cargo clippy --locked --all-targets -- -D warnings: exit 0.
• cargo test --locked: 367 passed, 3 explicitly ignored, 0 failed, including 2 documentation tests. Selected Docker/VM suites were not run.
• cargo build --locked --release: exit 0.
• git diff --check: exit 0.

Base commit: fe7e3d61c22108acba5c4a86480254a12e089a53. Dirty inputs and SHA256 at validation:

• Cargo.toml: 807d08cc43b4c3f986134b7aa5b051fd2f0966fab95ac01d861c65f173c77caa
• Cargo.lock: 6a929bb72d90da16b5ca7d209566e31a611d1ddcd5817ee778d7e9fe25b10c2e
• src/service/dbus.rs: d1ed34dd8a46d2495299c776176d7d5f6cfa9b6abb29ec84b6045e74bdffeb26
• docs/DEPENDENCIES.md: 1db85ecd3f892e3f42f1220eb7627cfd423406e46e5024bdf6599a647f07be1f
• docs/TESTING.md: 7ecab091999b50964b1641772a4cfc370639507b9c6621a058829a54b0f71325

Native release artifact target/release/wireguard-admin SHA256: 64c2851431ec406901e76dc866a05abd630a0e71adfd4efc16d3b44ea3c72b73.

The prior disposable Debian VM was stopped before guest installation and has no verified guest marker or running systemd acceptance environment, per VM_ACCEPTANCE.md. No private-socket or system-bus restart was run in a disposable VM. Neither transport is accepted against real systemd yet; production must not be used to fill this gap. The next check is to finish and authorize a disposable VM with synthetic WireGuard configuration, then run both transport paths and verify job completion plus full runtime matching, with exact source/artifact identity.