# RustDesk client packaging for rustdesk.bosner.de

This directory contains the reproducible client-side configuration for the OSS rollout.

## Current delivery model

- Windows portable packages are byte-for-byte copies of the official RustDesk 1.4.9 EXE files. Their filenames carry `host` and `key`, which the Windows client parses at startup.
- `windows/install-rustdesk.ps1` installs that upstream binary, applies `host`, `relay`, HTTPS `api` and `key` with the supported `--config` interface, enables direct IP access on TCP 21118 and verifies the resulting settings.
- `windows/configure-rustdesk.ps1` repairs an existing Windows installation, adds a TCP 21118 firewall rule limited to `LocalSubnet`, restarts the system service and verifies that its persistent configuration points at the private server.
- `macos/install-rustdesk-macos.sh` installs the official upstream DMG for the current CPU architecture, applies the same configuration and verifies it.
- `macos/configure-rustdesk-macos.sh` applies and verifies the same settings on an existing `/Applications/RustDesk.app` without reinstalling it.
- The HTTPS management API is configured explicitly. No unattended-access password is embedded.

All downloaded upstream artifacts are pinned by SHA-256. Renaming a Windows EXE does not alter its bytes or its upstream Authenticode signature.

## Native custom builds

`patches/rustdesk-1.4.9-bosner-defaults.patch` changes only the built-in rendezvous server and public key. Apply it to the exact `1.4.9` source tree before using the upstream Flutter build workflow:

```sh
git checkout 1.4.9
git apply --check /path/to/rustdesk-1.4.9-bosner-defaults.patch
git apply /path/to/rustdesk-1.4.9-bosner-defaults.patch
```

The current upstream `playground.yml` declares `RENDEZVOUS_SERVER`, `RS_PUB_KEY` and `API_SERVER`, but the client source does not consume those environment variables. The explicit patch is therefore the auditable build input.

Release-grade native packages require:

- Windows: an Authenticode code-signing certificate or signing service.
- macOS: Developer ID Application/Installer identities and Apple notarization credentials.

Until those credentials exist, the wrapper approach keeps the official upstream application signatures intact.