electron-builder 26.17.0: NSIS store-asar mode and differential-update fixes

What happened on 2026-09-26

At 09:52 UTC on 2026-09-26, electron-builder published electron-builder@26.17.0 on GitHub; apart from the release commit, the changes were backports to the v26 line. The release notes list a new NSIS 'store-asar' mode for proportional differential updates (#10201); electron-updater keeping its cached blockmap consistent with the cached installer (#10163); multi-range differential downloads that now work on real servers (#10219); rootVolumeOnly added for the macOS 26 Installer prompt in pkg (#10211); a fix for linux.files corrupting Flatpak files (#10229); and several fixes to pnpm dependency collection and Windows workspace-root detection. The release page only gives the pull request title for store-asar. It does not explain how the mode works, how to configure it, or what the trade-offs are; confirming those requires reading the PR or the documentation.

What it means for protecting Electron apps

The fact that asar is only an archive format already has its own guide, so it is not repeated here. What deserves attention in this release is the update pipeline. Teams protecting Electron apps often post-process app.asar after the build, for example by computing integrity hashes, swapping in a hardened version, or verifying files at startup. If the way asar is stored in the installer, or the way differential updates are computed, changes, the assumptions behind those post-processing steps may no longer hold. A hash may be computed against the old layout, or a differential patch may not match the post-processed file. Issues such as a cached blockmap falling out of sync with the installer affect whether updates land correctly at all. To be honest about it: the release page gave no implementation details for store-asar, so we cannot claim it breaks any specific scheme. It is simply a change point that needs testing.

Checks to run on your own builds

First, if you post-process app.asar, read the corresponding PR before enabling store-asar mode, and run the full install, differential-update and startup-verification flow once on a test channel. Second, on Windows, confirm that update packages and installers still carry valid code signatures and that electron-updater's signature verification has not been disabled. Third, test multi-range downloads against your real update server rather than a local file server. Fourth, before each release, compare the file list and hashes of the installed resources directory between old and new versions and confirm they match expectations.

Your checklist

• Read the PR and test the full flow on a test channel before enabling store-asar
• Confirm update packages are signed and updater signature checks are enabled
• Compare installed resources file lists and hashes across versions