Windows 1.0.17: signed update metadata and package verification

Windows version 1.0.17 was announced on 8 August 2026. The release focused on the update path and several safeguards around local operation. This article describes the mechanisms in the original announcement; it does not certify an arbitrary installer or every later client version.

Signed update information

The announcement described Ed25519 signatures for update metadata. In an update system, signed metadata lets the client check that the version and download information were authorised by the expected signing key. A successful check depends on the trusted key and the verification actually performed by that client version.

A secure update process should stop when a required signature is missing or invalid. Users should use the official update entry instead of installing a package supplied by an unknown person as a repair.

Checking the downloaded file

The release also described checks of package size and SHA-256. These compare the received file with the expected package information and help detect a corrupted or substituted download. A hash on its own does not prove publisher identity; its value comes from checking it against trusted update information.

If a download check fails, retry through the official client or website. Do not rename a broken file, bypass the check or accept a replacement from an unofficial channel.

Local core authentication

The release note described authentication for local communication with the connection core. This helps restrict access to the local control interface. It does not remove the need to keep Windows updated, protect the user account and avoid running untrusted software.

Download fallbacks

The update path included alternative official download locations to help when one route was unavailable. A fallback should still identify the same intended package and pass the same integrity checks. Changing the source is not a reason to weaken verification.

Use the official downloads page if the in-app update cannot complete. A network block, full disk or endpoint protection message should be diagnosed according to the actual error.

Diagnostics under user control

The announcement described diagnostics initiated by the user to help support investigate failures. Read the current diagnostic screen before sending a report. Do not paste complete logs into public groups or include passwords, recovery codes, payment details or unrelated private content.

Support usually needs a limited description: Windows version, client version, failure time, connection state and whether another network or route changes the result.

Update and verify the result

1. Start the supported official update flow or download the current installer.
2. Let the client verify the update information and received package.
3. Reopen the app and confirm the displayed version.
4. Check membership and connect on your normal network.
5. Test a trusted HTTPS website and the service you need.

If Windows reports a security problem, first identify the type of warning and verify the publisher and download origin. The installation security guide and Windows setup guide explain the next steps.