Skip to content

Husk v0.1.7 - Auto-updater hardening

Choose a tag to compare

View all tags
@runhusk runhusk released this 29 Jun 19:48
v0.1.7
ad1e7d0

Husk v0.1.7 - Auto-updater hardening

Patch release. One critical fix to the auto-update flow.

Downloads

File Size SHA-256
Husk-Portable-0.1.7.zip 2.2 MB 6a5887d69740074254632fe21e12614aa93d417b73796b8ac94bbb4361ad38b2
husk.exe (standalone, for in-place update) 4.6 MB 7bf1a3e8dfb2a1f5c4a1c8bc76ad8cf7e71fb057ee186acc0d69b7f0e896a664

Verify before running

Get-FileHash .\Husk-Portable-0.1.7.zip -Algorithm SHA256

Match the output against the hash above. If it differs, do not run.

What's fixed

Auto-update from v0.1.6 produced an unrunnable binary

In v0.1.6 testing the bundled streaming downloader inside self_update
truncated mid-flight under some network conditions, 3.7 MB landed on
disk where the actual husk.exe is 6.2 MB. The chunked-encoding read
returned success without ever checking that everything had arrived.
The replace step then dropped that incomplete file in place of the
running Husk, and Windows refused to launch the next time with:

Cette application ne peut pas s'exécuter sur votre PC.
(This app can't run on your PC.)

That's the OS-level signal for a corrupt PE header.

The new pipeline

v0.1.7 rewrites install_update to bypass self_update's downloader
entirely. We still use the crate for release discovery (auth-free
GitHub API client, semver sorting), but the actual binary fetch goes
through ureq with three sanity checks before the live-binary swap:

  1. Size check. The temp file is compared against the GitHub asset's
    Content-Length. A truncated 3.7 MB body of an expected 6.2 MB
    asset is now rejected with a clear error.
  2. PE magic. The first two bytes of the downloaded file must be
    MZ. An HTML error page, a 0-byte redirect body, or anything else
    that isn't a Windows executable is refused.
  3. Same-volume staging. The temp file is written next to the
    running binary so self_replace's rename is a single cheap
    filesystem op on the same volume, no cross-volume copy that an
    antivirus lock could partially complete.

On any failure the update is aborted and the running binary is left
untouched. Errors land verbatim in Settings → About so the user knows
to retry or fall back to manual update.

Upgrade path

  • From v0.1.6: your install carries the buggy v0.1.6 updater, so
    the in-app update flow can't be trusted for this one transition.
    Download husk.exe (above) and replace it manually.
    After that, in-app updates from v0.1.7 onward will go through the
    new safer path.
  • From v0.1.5 or earlier: same in-app update flow as before.
    v0.1.5's self_update flow lands you on v0.1.7 directly; the
    truncation bug appeared during v0.1.6 testing but the underlying
    failure mode is independent of which version you start from, so
    some networks may fail there too, if it does, replace husk.exe
    manually.
  • First install: download the zip or standalone husk.exe from
    the download page, extract or drop in place, run.

What's unchanged from v0.1.6

All four browser-feel fixes shipped in v0.1.6: fullscreen handoff,
silent 204 blocked-request response, expanded bundled baseline filter
list, DoH-routed EasyList refresh are still there. v0.1.7 only
touches the updater.

Known limitations carried over

  • macOS + Linux still v0.2 targets.
  • Taskbar pin AUMID identity remains consolidated by Windows Shell
    in dev setups where multiple husk.exe binaries live on the same
    machine.

If Husk is useful to you, support keeps it free, ad-free and
account-free: husk.run/donate.

Assets 4
Loading