MyVNC 0.10.1

0.10.1

Date: 2026-09-27
Commit range: v0.10.0..v0.10.1 (release commit included)

Included commits (in git order, v0.10.0 excluded):

1. docs: point README at the 0.10.0 installer
2. build: upload CI test results only when tests fail
3. docs: describe server verification, build prerequisites and all known limitations in README
4. docs: cover pin store, download names and per-address pinning in SECURITY.md
5. build: Bump the test-stack group with 3 updates (#1)
6. fix: stop hidden reconnects after closing session windows
7. release: bump version to 0.10.1 (this commit)

Summary

Fixes a reconnect loop seen against a wayvnc host with a single-client guard. Closing a session
window with its X button previously left its tab's retry task running. A newly opened window then
created a second VNC connection, and the server's guard disconnected the older one on each new
connection. Both invisible and visible sessions could keep reconnecting and displacing each other.

Window close now cancels the tab's pending and in-flight connections, releases its RFB transport,
and ignores late callbacks. A connection that is dropped immediately after a successful handshake
also counts as a failed reconnect; three such attempts close the tab rather than resetting the
counter and retrying forever.

Changes

See CHANGELOG.md for the full list.

Upgrading

No data migration. Install over 0.10.0.

Regression testing done for this release

• dotnet build MyVNC.slnx -c Release passed with no warnings.
• dotnet test tests/MyVNC.Rfb.Tests -c Release passed (49/49).
• scripts/smoke-test.ps1 passed, including app launch, single-instance behavior, idle memory,
  and shutdown.
• The self-contained installer was built and installed locally in silent mode. The installed
  binary matched the build and the installed app started successfully.

Risks

• The window-close and retry behavior is covered by code review and a successful build, but no
  automated WPF interaction test exercises the original two-window sequence.

MyVNC 0.10.0

0.10.0

Date: 2026-09-26
Commit range: v0.9.2..v0.10.0 (release commit included)

Included commits (in git order, v0.9.2 excluded):

1. docs: point README at the 0.9.2 installer
2. docs: add MIT license
3. docs: add security policy with private reporting and known limitations
4. build: add .gitattributes and a GitHub Actions build-and-test workflow
5. docs: replace internal AGENTS.md with an English CONTRIBUTING.md
6. docs: translate release notes and changelog to English
7. docs: link license, security policy, contributing guide and CI in README
8. fix: release the RFB transport immediately on disconnect
9. fix: ignore stale render and disconnect callbacks from a closed session
10. docs: update a commit reference changed by the history rewrite
11. fix: verify the VNC server's identity before sending credentials
12. fix: pin TLS certificates and SSH host keys with trust on first use
13. fix: validate SSH terminal targets and pass them as separate arguments
14. docs: document server identity verification in SECURITY.md and CHANGELOG
15. build: ship license and third-party notices with the installer
16. build: add Dependabot for NuGet packages and GitHub Actions
17. release: bump version to 0.10.0 (this commit)

Summary

A security release, and the first version prepared for a public repository.

Up to 0.9.2 MyVNC trusted every server it talked to. The VeNCrypt TLS handshake accepted any
certificate, the SFTP file-transfer side channel accepted any SSH host key, and VeNCrypt picked
the unencrypted Plain sub-type whenever a server offered it — all before sending the username
and password. Anyone able to intercept the connection could have captured the credentials.

The RFB library now has a server-identity hook that runs after security negotiation (and after
the TLS handshake) but before any credential is sent, and prefers the TLS-wrapped sub-types over
Plain. The app plugs trust on first use into it: the first connection to an address shows the
certificate's SHA-256 fingerprint, together with the command that prints it on the server, and
pins it once accepted. A changed certificate is a warning that defaults to refusing, a pinned
host that suddenly offers no TLS is refused as a downgrade, and a rejected server is not
auto-reconnected to. SFTP verifies the SSH host key the same way.

Two smaller hardening fixes came out of the same review: remote file names that could escape
the chosen download folder are refused, and the SSH terminal shortcut validates the host and
username and passes them as separate process arguments instead of building a command string —
previously a crafted profile could run commands or inject ssh options.

Testing the new code against real hosts surfaced one more bug: a failed or rejected handshake
left its socket open until the next attempt, which could hold the only slot on a single-client
wayvnc server. It is now closed immediately. Two earlier session-teardown fixes (releasing the
transport at once on close, and ignoring late callbacks from a closed session) are also part of
this release.

The rest is groundwork for going public: an MIT license, a security policy with private
vulnerability reporting, a contributing guide in English, English release notes, a CI workflow,
Dependabot, and license notices shipped with the installer.

Changes

See CHANGELOG.md for the full list.

Upgrading

No data migration. The first connection to each saved address after upgrading shows a
"Verify server identity" prompt with the server's certificate fingerprint, and the first file
transfer to each host shows one for the SSH host key; compare them with the server's before
accepting. Fingerprints are pinned per address, so a host reached via both a LAN IP and a
Tailscale address prompts once for each. Pinned fingerprints live in
%APPDATA%\MyVNC\known_hosts.json; "Forget saved host keys" (formerly "Forget SSH host key") on
a connection's edit page clears them.

Regression testing done for this release

• dotnet build (Debug + Release) green with no warnings; dotnet test green (49/49, including
  six new handshake tests against a scripted loopback server: TLS preferred over Plain, the
  identity check running and able to abort before credentials are sent, the certificate
  fingerprint of a real self-signed TLS handshake, and the socket closing on rejection).
• scripts/smoke-test.ps1 passed against the Release build.
• Live-verified against two real wayvnc hosts, with reference fingerprints taken
  independently of MyVNC (a separate VeNCrypt probe for the certificates, ssh-keyscan for the
  host keys), driving the app via UI automation:
  • First connection: the prompt showed exactly the reference certificate fingerprint; accepting
    it connected and pinned it. After an app restart the same host connected without a prompt.
  • A tampered pin (simulated man-in-the-middle): the "changed" warning appeared; refusing it
    closed the socket within 1.5 s, showed the rejection in the session, and caused no further
    prompt or reconnect.
  • SFTP "Receive file": first use showed the reference ED25519 host key fingerprint and listed
    the remote files after accepting; a second listing did not prompt; a tampered host key was
    warned about and, once refused, blocked the listing.
  • The SSH button launched Windows Terminal running ssh <user>@<host> with the target as a
    separate argument; the validation patterns rejected shell metacharacters, quotes and
    -o... option injection while accepting real IPv4/IPv6 addresses and host names.
• Installer built and installed per-user (installer\build-installer.ps1, silent install), and
  the app verified to start from the installed binary, with LICENSE.txt and
  THIRD-PARTY-NOTICES.txt present in the install folder.
• Not live-verified: the TLS downgrade refusal (both test hosts only offer X509Plain, so it
  is covered by unit tests only), and the SSH target validation's error dialog in the GUI.

Risks

• Trust on first use protects every connection after the first; if the very first connection to
  an address is already intercepted, the attacker's fingerprint gets pinned. The prompt shows the
  server-side command to compare against for exactly this reason.
• If the fingerprint prompt stays open longer than wayvnc's handshake timeout (around 30 s),
  wayvnc drops that attempt. With auto-reconnect on (the default) the next attempt connects
  without a prompt, since the fingerprint is pinned by then; with it off, click Connect again.