fix: Allow EnableEmbeddedAsarIntegrityValidation when multiple asars are present in app
#124
Conversation
…tyValidation` fuse breaks the application due to not all ASARs having integrity generated for them. Fixes: electron#116
…ar-integrity # Conflicts: # test/index.spec.ts
mmaietta
force-pushed
the
multi-asar-integrity
branch
from
e37218f to
61eb5ac
Compare
|
🎉 This PR is included in version 2.0.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
| } | ||
| } | ||
| if (p.includes('app.asar')) { | ||
| if (p.endsWith('.asar')) { |
There was a problem hiding this comment.
@BlackHole1 this changed the way some resources are identified i.e. before:
{
"relativePath": "Contents/Resources/app.asar",
"type": 4
},
{
"relativePath": "Contents/Resources/app.asar.unpacked/node_modules/fsevents/fsevents.node",
"type": 4
},And after:
{
"relativePath": "Contents/Resources/app.asar",
"type": 4
},
{
"relativePath": "Contents/Resources/app.asar.unpacked/node_modules/fsevents/fsevents.node",
"type": 0
},(4 = APP_CODE and 0 = MACHO)
I'm not sure if that's intentional or not but in the second case, it's considering fsevents.node as MACHO instead of APP_CODE and it leads into running this check here for this file where it wouldn't hit it before, leading to this error for Electron apps that includes the fsevents package and other packages with universal .node binaries:
Error: Detected file "Contents/Resources/app.asar.unpacked/node_modules/fsevents/fsevents.node" that's the same in both x64 and arm64 builds and not covered by the x64ArchFiles rule
Do you think in the above example app.asar.unpacked/.../fsevents.node should be identified as APP_CODE or MACHO? Trying to figure out what a fix for this would look like
If it should stay APP_CODE, maybe doing if (p.includes('.asar')) is a good enough fix..., or maybe p.endsWith('.asar') || p.includes('.asar.unpacked/') to be stricter
Edit: made a PR #133 with a tentative fix
There was a problem hiding this comment.
I disagree that all contents in unpacked folder should be APP_CODE, as .node is a macho file. I think your issue being reported here:
other packages with universal .node binaries:
Should be resolved through #126 though
There was a problem hiding this comment.
Oh, even better! I'll watch that PR and pin 2.0.1 in the meantime then, thanks for the pointer 👌
PR electron#124 introduced a regression where the following path: Contents/Resources/app.asar.unpacked/node_modules/fsevents/fsevents.node Would get identified as `AppFileType.MACHO` instead of `AppFileType.APP_CODE` as it was previously We need to make sure that path containing `.asar.unpacked/` are also treated as `APP_CODE`
3 participants
webapp.asar,anything.asar, etc.),EnableEmbeddedAsarIntegrityValidationfuse breaks the application due to not all asars having integrity generated for them. Fixes: ASAR Integrity assumes a single asar file is present #116makeUniversalApp no asar mode should shim two different app folders, (it was not having an asar integrity generated for the shimmed asar)Functionality added:
integrity.ts