Add rosenpass connection type and docs

[MahmoudAdelbghany]

Implements netctl-side support for Rosenpass over WireGuard.

Changes:

• add a new rosenpass connection type in src/lib/connections/rosenpass
  • creates the WireGuard interface
  • starts rosenpass exchange-config in the background
  • tracks and stops the process on profile shutdown
• document profile options in docs/netctl.profile.5.txt
  • RosenpassConfigFile=
  • RosenpassBinary=
• add docs/examples/rosenpass
• add rosenpass optional dependency in contrib/PKGBUILD.in

Refs: rosenpass/rosenpass#80

/claim #80

[joukewitteveen]

How was this tested? Superficially it looks like a good start.

[MahmoudAdelbghany]

Thanks for the review — I ran full verification and uploaded all artifacts.

What I tested

• Scripted connection smoke tests for the new netctl rosenpass connection logic (success + failure/cleanup paths).
• Full runtime Rosenpass+WireGuard+netctl smoke test in an isolated user/network namespace:
  • Rosenpass key exchange completed.
  • WireGuard PSKs were set on both peers.
  • WireGuard handshakes and transfer counters were observed.
  • Ping between peers succeeded.

Attached artifacts (including video)

Release with all files:
https://github.com/MahmoudAdelbghany/netctl/releases/tag/issue80-verification-artifacts-20260308

Direct files:

• Scripted test log: https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/01-scripted-tests.log
• Runtime smoke log (source-build rosenpass): https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/02-runtime-smoke-sourcebuild.log
• Demo video (mp4): https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/03-runtime-demo.mp4
• wgA PSK evidence: https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/04-wgA.psk.txt
• wgB PSK evidence: https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/05-wgB.psk.txt
• wgA show output: https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/06-wgA.show.txt
• wgB show output: https://github.com/MahmoudAdelbghany/netctl/releases/download/issue80-verification-artifacts-20260308/07-wgB.show.txt

If you prefer a different test matrix (e.g., specific kernel/netctl versions), I can run that too.

[joukewitteveen]

All well and good, but I am a human pressed for time with an understanding of the upstream guide and I don't see how the current pull request deals with the peer/endpoint distinction and what parts of the logic in the rp tool we support.

[MahmoudAdelbghany]

This PR is a netctl wrapper around rosenpass exchange-config.
It does not implement rp exchange parsing or logic.

Peer/endpoint behavior is defined in the Rosenpass TOML. If
[[peers]].endpoint is set, that peer initiates the exchange. If it is
omitted, the peer only listens.

This PR focuses on netctl lifecycle integration:

• interface_add/delete
• rosenpass start/stop
• ip_set/ip_unset

It also includes manpage, example, and PKGBUILD updates.

Key/config generation and peer modeling remain handled by Rosenpass
configuration rather than by netctl.

[joukewitteveen]

Thanks for the clarification so far. For reference, what happens (i.e. what commands are run) when

rp exchange server.rosenpass-secret \
  dev rosenpass0 \
  listen $SERVERIP:9999 \
  peer client.rosenpass-public \
  allowed-ips 192.168.21.0/24

is executed on the server, or when

rp exchange client.rosenpass-secret \
  dev rosenpass0 \
  peer server.rosenpass-public \
  endpoint $SERVERIP:9999 \
  allowed-ips 192.168.21.0/24

is executed on the client?

[MahmoudAdelbghany]

On those two examples, rp exchange does the following.

For both sides:

• creates WireGuard interface dev rosenpass0 (or default rosenpass0 if dev omitted),
• sets WG private key,
• sets WG listen port to listen_port + 1 when listen is set,
• starts Rosenpass on the configured listen socket,
• for each peer, adds ip route replace <allowed-ips> dev <dev>,
• on key updates, calls wg set <dev> peer <peer_wgpk> preshared-key /dev/stdin plus extra params.

Server command (listen $SERVERIP:9999, no peer endpoint):

• Rosenpass listens on $SERVERIP:9999.
• WG listen port is set to 10000.
• For that peer, wg set extra params include allowed-ips 192.168.21.0/24 (no WG endpoint param).

Client command (peer endpoint $SERVERIP:9999):

• Rosenpass uses peer endpoint $SERVERIP:9999 for RP traffic.
• WG endpoint passed to wg set is $SERVERIP:10000 (+1 rule).
• wg set extra params include endpoint $SERVERIP:10000 and allowed-ips 192.168.21.0/24.

So the endpoint distinction is: Rosenpass uses the RP endpoint as configured, while the WG endpoint for that peer is derived as RP port + 1.