Utly Remote remote.utly.dev

Beta

Utly Remote 0.2 is complete enough to use every day, and the beta exists to find what breaks on PCs, networks and Windows editions the developer does not own. This page is for the people testing it: how to join, what to try, how to report, what a crash report is, and what every build goes through before it reaches you.

Joining

There is no sign-up. Install from remote.utly.dev — the installer, the portable exe, or the Windows 7 build — and turn on Settings › About › Beta channel. Beta builds land on that channel first and become the stable release once they have held up for two weeks; the update check runs half a minute after start and every six hours, and the app asks before it restarts.

If you are helping the developer directly, say which machines you run it on (edition, installer or portable, host or viewer, the network you sit behind); that is what decides which rows of the VM matrix still need a real PC.

What to try

Use it for what you would use any remote desktop for, then go down this list once. Each line is something that has a test on the developer’s machines and has not yet met yours.

  1. Install both ways: the installer on one PC (the service comes with it), the portable exe on another. Sign out and back in; the installed one starts in the tray when you sign in, and its host service was reachable before that.
  2. Connect in both directions. On the accept card, check the four words match on both screens.
  3. Switch each permission off and on during a session — keyboard and mouse, clipboard, audio, files — and confirm the other side loses and regains it at once.
  4. Unattended access: set a password, connect with it from the other PC, then turn on Ask on screen even when the password matches and connect again. Type the password wrong five times and read the lockout line in the session log.
  5. With the service: connect to a PC showing the logon screen, send Ctrl+Alt+Del, answer a UAC prompt, restart the PC from the session and wait for it to come back.
  6. Monitors: a PC with two or more screens, View all, then unplug or plug a monitor during the session.
  7. Files: a large file each way through the files panel, drag and drop onto the session window, cancel one half-way.
  8. Clipboard text both ways; audio from a video playing on the host.
  9. Pull the network cable on one side for ten seconds. The session should come back on its own.
  10. An account: sign up, sign in on a second PC, approve it from the first, revoke it from the second, sign in again with a recovery code. Rename a machine in the address book on one PC and read the name on the other.
  11. An update: leave the beta channel on and let the next build arrive; on a portable exe the previous file should sit next to it as .previous until the new one has started once.
  12. Windows 7, 8 or 8.1 as host with remote-win7.exe, with and without update KB4474419.

Reporting

Bugs go to the repository’s issue tracker with the bug template. Say the version (Settings › About), the Windows edition, installer or portable, which side you were on (host or viewer), and attach the log file from Settings › About — it holds no passwords and no session content — and the crash report if there was one. A minimal way to reproduce is worth more than a long description.

Security findings go through private vulnerability reporting, never a public issue.

Someone told you to install this — a caller, a message, a pop-up: hang up, then use Report an ID in Settings › Security. The safety page says why.

Not bugs: the limits the threat model lists under Not covered before 1.0, and what the server notes say about RDP sessions and Server Core.

Crash reports

A crash — a panic in any of the program’s processes — writes a text file to crashes\<time>-<role>.txt in the data folder shown in Settings › About: the version, the role (app, agent, service or win7), the Windows edition and build, the time, and the panic message with the source file and line it came from. Your profile path is replaced by ~. The newest twenty are kept. Nothing from the screen, the clipboard or a transfer is in a report, because the crash handler has no access to them.

Nothing leaves the PC until you say so. Settings › About › Crash reports shows how many are waiting, with Send and delete; the switch Send crash reports automatically sends them when you turn it on and at every start after that, and applies to the service side too. The Windows 7 shell has the switch only. A report is posted to broker.utly.dev/v1/crash and stored with your IP address and the time; a person reads it with utly-remote-broker crashes and deletes it when the crash is fixed. The privacy page lists exactly this.

Reports written by the service and its agent sit in %ProgramData%\Utly Remote\crashes, which only administrators can read, so the app’s count does not include them; they are sent when the switch is on, or you attach them by hand.

Not captured: a fault that is not a Rust panic, such as an access violation inside a codec or a display driver call. Windows Error Reporting records those under Windows Logs › Application in Event Viewer as an application error with a faulting module; that entry in a bug report is the next best thing.

Release checklist

What a build goes through before it reaches the beta channel:

  1. scripts\check.ps1 is green: formatting, clippy with every pedantic lint on both builds, the tests, the release build, the Windows 7 build, the frontend, cargo deny.
  2. scripts\fuzz.ps1 -minutes 10 finds nothing on the four targets. The long run — six hours per target — belongs to the beta period, on a spare machine.
  3. The VM matrix: the smoke session on rows M1, M3, M4 and M6, and on M7 whenever capture or the service changed. Any row the build’s changes touch, in full.
  4. scripts\release.ps1 builds and signs the portable exe, the installer, the Windows 7 exe and the update artefacts; scripts\publish.ps1 -channel beta -rollout 100 uploads them with a signed manifest.

What a beta build goes through before it becomes stable:

  1. The NAT matrix: a session on the same LAN, one between two home routers (a direct path after hole-punching), one from a mobile or hotel network (the relay path), each confirmed by the viewer’s status line saying P2P direct or via relay.
  2. An in-place update from the previous stable on an installed PC with the service running (the service stops, the program is swapped, the service comes back, the session log continues) and on a portable exe (the previous file is kept, then removed after the first good start). A portable build that starts but never settles is put back to the previous file at its next launch; rehearse it once on a copy.
  3. A fresh-install run-through by someone who is not the developer, from the download page to a first session, with no help beyond the help page.
  4. Two consecutive beta weeks with no P0 and no unresolved complaint about key pinning or sign-in, with utly-remote-broker crashes and reports read every day of them.
  5. scripts\publish.ps1 -channel stable -rollout 10, then 50, then 100 on the following days, watching the same two commands after each step.