disable asarIntegrity and computeData call

[nikitakot]

I'm using custom patched electron build with encrypted asar archive support.

I also don't use EnableEmbeddedAsarIntegrityValidation fuse and disable it explicitly via @electron/fuses during build.

My build now fails with:

failed to build distributable RangeError: The value of "offset" is out of range. It must be >= 0 and <= 4. Received -2404272720
    at boundsError (node:internal/buffer:88:9)
    at readUInt32LE (node:internal/buffer:222:5)
    at Buffer.<anonymous> (node:internal/buffer:1003:50)
    at PickleIterator.readBytes (/Users/runner/work/exams-client/exams-client/node_modules/chromium-pickle-js/lib/pickle.js:65:21)
    at PickleIterator.readUInt32 (/Users/runner/work/exams-client/exams-client/node_modules/chromium-pickle-js/lib/pickle.js:39:17)
    at readAsarHeader (/Users/runner/work/exams-client/exams-client/node_modules/app-builder-lib/src/asar/asar.ts:160:40)
    at hashHeader (/Users/runner/work/exams-client/exams-client/node_modules/app-builder-lib/src/asar/integrity.ts:84:22)
    at async Promise.all (index 1)
    at computeData (/Users/runner/work/exams-client/exams-client/node_modules/app-builder-lib/src/asar/integrity.ts:73:18)
    at MacPackager.doPack (/Users/runner/work/exams-client/exams-client/node_modules/app-builder-lib/src/platformPackager.ts:321:25) {
  code: 'ERR_OUT_OF_RANGE'

By quickly looking at the code it seems like computeData tries to read my encrypted asar and fails.

What's the best way to fix that? Is a new flag required?

I was submitting a similar issue couple years ago - #8122

env info

$ cat package.json | rg electron
...
    "electron": {
    "electronVersion": "41.1.0",
...
    "@electron/fuses": "^2.1.1",
    "@electron/notarize": "^3.1.1",
    "@types/electron-devtools-installer": "^2.2.0",
    "electron-builder": "^26.8.1",
    "@sentry/electron": "7.10.0",
    "electron-store": "^8.2.0",
    "electron-updater": "^6.8.3",

[nikitakot]

upd.: The "regression" happened somewhere between 26.0.12 and 26.8.1. I can still successfully build my app on 26.0.12

[nikitakot]

the regression probably happened here - 45a402b

[mmaietta]

So I did some deeper investigation and debugging here and leveraged both copilot and claude for git history tracking.

I'm honestly not sure why 26.0.12 works for you. Through the multiple scans, no changes were reported in the versions delta/diff; the computeData logic path has been long-standing
https://github.com/electron-userland/electron-builder/compare/v26.0.12...electron-builder@26.8.1

Per Claude's analysis:

This was always a latent problem — computeData has been in the codebase since [2017 commit 3e28ae2] ("feat: asar integrity (macos only for now)") with no user-facing way to skip it. Commit 45a402b didn't introduce this — it was always there.
Before 45a402b:

// positional parameter
protected async doPack(..., sign = true, disableAsarIntegrity = false) {
  asarIntegrity: asarOptions == null || disableAsarIntegrity ? null : await computeData(...)
}

After 45a402b:

// options object
const { ..., options } = packOptions
asarIntegrity: asarOptions == null || options?.disableAsarIntegrity ? null : await computeData(...)

For a regular (non-universal) mac build, the caller never passes disableAsarIntegrity/options.disableAsarIntegrity. In both cases the guard evaluates to false and computeData is called either way. The behavior is identical.
What 45a402b actually did was:

• Refactor doPack from positional params → options object
• Add universal build handling where intermediate x64/arm64 builds correctly pass { disableAsarIntegrity: true } to skip integrity on those temp builds
• The root cause of disable asarIntegrity and computeData call #9677 predates 45a402b — it's that computeData has always been called unconditionally when asarOptions != null, regardless of whether the ASAR is encrypted.

---

So, we might indeed need another config prop to enable disabling integrity checks. Alternatively, we can key it off of electronFuses.EnableEmbeddedAsarIntegrityValidation === false, but I'm not sure if that'll leave any edge cases? What are your thoughts?

Honestly, I'm tired of adding additional config props for niche use cases like this; electron-builder's configuration is already complex as it is.

Nonetheless, I'd like a more extensible way to solve for flows like this so we can resolve this for you.

Two routes:

• electronFuses.EnableEmbeddedAsarIntegrityValidation === false means we only disable the pathway if explicitly the fuse is disabled
  OR
• electronFuses.EnableEmbeddedAsarIntegrityValidation !== true since electron has integrity verification disabled by default.

What are your thoughts on keying asar integrity computation based on the fuse itself? What are your thoughts on the two routes?

[nikitakot]

@mmaietta

What are your thoughts on keying asar integrity computation based on the fuse itself? What are your thoughts on the two routes?

will this work if fuses are set outside of eletron-builder? I'm not using fuses feature of electron-builder and I set these fuses manually via the native electron fuses library during build

in my opinion there should be an option to explicitly opt out from fuses and all related logic in electron builder