v1.0.0

Warning

This release contains unsigned artifacts.

The run was dispatched with allow_unsigned=macos,windows, so the following platforms were published without a code signature:

• macos — the .dmg and the .app inside it carry no Developer ID signature and are not notarized. macOS Gatekeeper refuses them until the user allows them by hand.
• windows — the NSIS installer (-setup.exe) carries no Authenticode signature. Windows SmartScreen refuses it until the user allows it by hand.

A code signature costs money — the Apple Developer Program is $99 a year and a Windows certificate is bought per year on top of that — and this project has no revenue, so the first release ships the artifacts without one. Everything else is signed: the Android APK carries the release keystore, the server archives carry a checksum, and the container image is signed with the release key and carries a provenance attestation.

The Tauri updater's own signature is separate from the operating system's and is present either way, so an update installs the same way as the first install does.

The third-party boundary is closed. A device's credential can be a key instead
of a shared secret, so a device that runs unattended needs nobody to read a code
to it; a client can be held to the ports it may reach and not only to the names;
relay_mode = "custom" really excludes n0's relays and [iroh] discovery
switches the address lookup off; the server's runtime state lives in a file of
its own beside the configuration; and both clients can bring the tunnel back by
themselves.

Nothing has to be enrolled again. The handshake, the ALPN and the L4 preface
are unchanged on the wire, so a 0.6.1 client talks to a 1.0.0 server and the
other way round. What did change is what a deployment and a device have to do.

Before upgrading

Two steps on the server are not optional.

1. The container image no longer runs as root. It runs as uid 1000, so the
three mounted directories have to be writable by that uid:

sudo chown -R 1000:1000 config secrets logs

Run it before the first start, and with sudo — the files the old root
image wrote are root-owned. Skipping it does not always fail loudly: an
iroh.key that cannot be opened is regenerated, which is a new Node ID, and
every client that stored the old one stops finding the server.

2. A config key the file does not know now refuses the start. In 0.6.1 only
[peers] and [auth] refused unknown keys and the rest dropped them silently;
every section refuses them now, the top level included:

unknown field `stray_key`, expected one of `default_backend`, `debug`, `routes`, `server`, `iroh`, ...
This build does not know that key: remove it, or fix its spelling.

Run the server once against your config and fix what it names. One key is worth
naming in advance: [admin] token is not a key — the admin token is
generated into <config>.admin-token and that file is the only source of it.

Three more things on the server, none of them a step you have to take.

• The runtime state moves into a file of its own: the counters
  (failed_attempts, locked_until, last_used) and the TOTP step memories
  go to a file named after the configuration — config.toml puts its state in
  config.state.toml. The old state.toml beside it is still read when the new
  one is not there yet, so existing lockouts survive. The configuration
  directory has to stay writable.
• Removed keys are still accepted and logged as ignored: [server] tls_enabled,
  tls_listen_addr, cert_path and key_path, the route-level cert_path,
  key_path and redirect_to_https, and the [acme] section. TLS is
  terminated by the backend now.
• Nothing else changed. No configuration key is removed or renamed, every key
  added in this cycle is optional, and [auth] enabled still defaults to
  false for a config that has no [auth] section — so an existing deployment
  does not suddenly demand a credential its clients were never given.

The clients.

• Nothing to enroll, nothing to rescan.
• Android: the tunnel's address block changes. It was 10.0.1.0/24 — which
  a great many home routers use — and is now the first block the host will take
  out of 198.18.0.0/24, 198.19.0.0/24, 100.100.0.0/24, 172.26.0.0/24,
  10.200.0.0/24 and 10.0.0.0/24. A rule of your own that hard-codes
  10.0.1.x needs updating.
• Desktop: the credentials move out of localStorage into an encrypted
  file whose master key the OS keychain holds. The migration is automatic.
• Desktop: the service is replaced during the upgrade. It runs a copy of the
  app's own binary from a root-owned directory, and an upgrade used to leave the
  service running the build it was started with — the app was new and the
  service was old, and the panel showed a service that was running with every
  button greyed out. The upgrade now puts the new binary in place; a service you
  had stopped stays stopped, the account it serves is unchanged, and if it
  cannot be done the installer puts the machine back the way it found it and
  exits with a non-zero code.
• New, and off until asked for: starting with the system, coming back after
  a reboot, and a device key instead of a secret.

What's new

A device can hold a key instead of a shared secret. A client can be held to
the ports it may reach. The third-party boundary is two settings now. Both
clients can stay up on their own. Both clients pick their address block, and
both sides spell a name the same way. A backend can be reached over TLS,
retried, and taken out of rotation. The protocol is chosen at the handshake.

The full list is in the changelog,
and the release notes — with the downloads and the checksums — are on the
pages site.