Can't start app from ZIP artifact

[pashvin]

• Version: 21.2.0

6.x

• Target: Mac/zip

Extract app from ZIP and try to start it, fails with "The application xyz can't be opened".

[jsgv]

I am experiencing the same thing.

I can open an unsigned build, but not a zipped up signed build.

macOS: Catalina 10.15 npm: 6.11.3 electron-builder: 21.2.0

[jsgv]

Partially solved with electron-notarize.

Due to Apple requirements on Catalina OS. https://developer.apple.com/news/?id=04102019a

[jookyboi]

@jsgv I'm using electron_notarize and it still fails for the same reason. Can you say more about how you got it to work?

[jookyboi]

Update: I've tried just compressing the .app/ folder with Finder->Compress and the unzipped app works fine on Catalina. It has something to do with the 7z compressor used from 7zip-bin. In the meantime, I'm trying to just use the native zip command to compress the folder.

[jsgv]

@jookyboi I mostly followed this article: https://medium.com/@TwitterArchiveEraser/notarize-electron-apps-7a5f988406db

Important details is creating the 'App-specific password'. Your regular apple credentials will not work. https://support.apple.com/HT204397

Note: The ZIPPED app still fails to open, but the DMG works. I have not tested the auto-update functionality, but I have read that it is also failing for now.

[jookyboi]

@jsgv I don't have an issue notarizing the app (and neither does the issuer filer). It has to do with using the zip build target for macOS. Something about the way 7z is compressing the app folder causes Catalina to reject opening the unzipped app.

[jsgv]

@jsgv I don't have an issue notarizing the app (and neither does the issuer filer). It has to do with using the zip build target for macOS. Something about the way 7z is compressing the app folder causes Catalina to reject opening the unzipped app.

@jookyboi You are correct. My mistake.

[jookyboi]

Update: Running from my Electron app's root folder: ../../node_modules/7zip-bin-mac/7za a -mm=Deflate -r [path_to_zip] [MyApp.app/]gives me a decently compressed zip file which still works fine on Catalina.

Can @develar look into removing some of the optional arguments for 7z to get things working again?

https://github.com/electron-userland/electron-builder/blob/b83f5801771585c18524c3cee74e59de5fa9ab30/packages/app-builder-lib/src/targets/archive.ts#L77

[jookyboi]

Update: 7zip has nothing to do with it. I tried with the max compression option from the command line and that still worked okay on Catalina. Something happening between zipping and final output is causing the issue.

[pashvin]

My application is notarized so there is no issue with it, having said that I don't know zip artifact waits for notarization to be finish. I can try to compare content from zip app vs dmg app and see that has any difference

[pashvin]

Ok I used following command to check app notarized or not from dmg and zip and it is confirmed that zip picked up app before notarization is done.

Command to check status of app: codesign --test-requirement="=notarized" --verify --verbose

[jookyboi]

@pashvin Good find. So the issue is that the folder get zipped up before notarization is complete? It just feels strange as my build process resulted in a properly notarized zipped app in Mojave.

How does this relate to the fact that the executable in the unzipped .app/ folder doesn't get execute permissions?

[jookyboi]

Here is the workaround I'm using until the problem gets fixed: https://snippets.cacher.io/snippet/354a3eb7b0dcbe711383

[bigshahan]

We've been experiencing the same issue and using a workaround similar to @jookyboi's.

[stevenroussey-privicy]

The last couple of days Apple has had issues with notarization, which if you do it by hand you would have noticed how long it took. Curious if the timing bug disappears when apple is running more smoothly today.

[pashvin]

No this is not a timing issue. This is always reproducible. I know notarization takes some time long and some time it is fast but I am tracking this issue from almost month and we have every day build. Every build has the same issue.

[jookyboi]

Update: Found the culprit: https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/targets/ArchiveTarget.ts#L65

After creating the zip, the default behavior for ArchiveTarget is to append the .blockmap to the file, then calculate the blockmapsize from that. This is in the name of doing differential updates.. though I've never seen electron-updater update this way for macOS.

I dug into node_modules/app-builder-lib/out/targets/ArchiveTarget.js and commented out this functionality:

if (this.isWriteUpdateInfo && format === "zip") {
  // updateInfo = await (0, _differentialUpdateInfoBuilder().appendBlockmap)(artifactPath);
}

The resulting latest-mac.yml will be missing the blockmapsize attribute but it doesn't seem to matter for me.

The resulting zip works fine on Catalina as does the auto-update functionality.

---

My theory is that by altering the zip file in this way (after compressing the notarized .app/ folder), we're confusing Catalina's Gatekeeper functionality.

[pashvin]

Yes once app is signed by apple, any modification will make signature invalid. I think those item must be added (if really required) before starting app notarization. Looks like we have some solution and need to generate an official build with fix.

[jookyboi]

I think the correct course of action would be to append the blockmapsize attribute, create the zip, then notarize the zip file itself. According to the docs, this should be possible: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

[pashvin]

There is no need to notarize zip, if anything is added to .app, then it need to be added before it sent for notarization so correct fix is add everything to .app before notarization start and then make zip once notarization is done. remember ZIP is not complaining anything , it extracts fine but .app is not able to start.

[pashvin]

what is the next step to get the fix. I think we already proved that this is a real issue so to get the fix what is the next step? Need to assign to some developer? Waiting for fix for this issue almost 3 month. I can't go back to older version because in that case i do not get any way to notarize app.

[semireg]

This is a very strange issue and I'll mention my findings because I haven't seen it mentioned here.

I had multiple Catalina users report "The application Label LIVE can't be opened." I downloaded and the app worked fine on Catalina. URL for reference and public reproduction: http://label.live/download.

I finally screen-shared (via Zoom) with a user and sure enough, the download app didn't work. They were using Chrome and the zip file was being decompressed by Archive Utility. I had the user download the same zip using Safari and presto, the decompressed app launched no problem. I have given this advice to other users with varying success. I believe that Safari users must have "Open safe files after downloading" checked. If not, then the Archive Utility is launched to unzip - causing the issue.

In all of my own tests I was decompressing with Safari's built-in unzipper (whatever that is)... can anyone confirm this issue with their builds? I'm skeptical that I'm the only one to notice this behavior...

[ansgarschulte]

@semireg I can confirm, that Safari downloaded app works for me and Chrome downloaded and Finder unzipped does not.

[semireg]

Apple developer support confirmed and helped me understand the issue. 🙌

The problem is that Archive Utility (only on Catalina) fails to create the proper symlinks when unpacking, whereas Safari "open safe" does create the symlinks as expected. An example of this is Contents/Frameworks/Electron Framework.framework/Versions/Current -> A

But, before we can blame Archive Utility, consider that unzip (on both Mojave and Catalina) fails to list the contents of the zip:

unzip -l Label-LIVE-1.4.6-10406006.zip
Archive:  Label-LIVE-1.4.6-10406006.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of Label-LIVE-1.4.6-10406006.zip or
        Label-LIVE-1.4.6-10406006.zip.zip, and cannot find Label-LIVE-1.4.6-10406006.zip.ZIP, period.

Apple developer support recommended ditto to create the zip, but I'm not sure if this is our end goal... I have not looked into how to fix/work-around electron-builder. Looking for help with that! 😅

/usr/bin/ditto -c -k --keepParent "$APP_PATH" "$ZIP_PATH" Reference: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow

Apple developer support also recommended filing a bug on this. I filed bug FB7400365 that describes this regression in Catalina's Archive Utility.

[jookyboi]

@semireg Thanks so much for looking into the issue and touching base with Apple. If you'd like to hack around with the zip creation, I would take a look at https://github.com/electron-userland/electron-builder/blob/f0bf67c7d87e7af4e31b24f45172cf4ba3c2ca72/packages/app-builder-lib/src/targets/archive.ts#L147.

The function explicitly calls 7zip to compress the .app/ directory. You may be able to swap out a few things there.

[IDmedia]

I've also noticed this issue, but can only reproduce it when zipping my .app file and uploading it to Dropbox or another remote location. When a user then downloads the file and unpacks the zip file on Catalina they also get the "App is damaged" message. Just zipping and unzipping the file locally works without issues.

[moughxyz]

Here is the workaround I'm using until the problem gets fixed: https://snippets.cacher.io/snippet/354a3eb7b0dcbe711383

There seems to be a problem with this snippet. If you compress the .app file, then immediately try extracting and running on Catalina (without running the blockmap script), it will work fine. If however you compress the .app file, then run the ./node_modules/app-builder-bin/mac/app-builder blockmap -i dist/[YourApp]-${version}-mac.zip command, this will modify the .zip file, and this file will then extract properly on Catalina, but the inner .app file will not run.

You can see that running the blockmap command many times will yield different signatures each time.

This means that you can't get both auto-update and zip download to work at the same time. Auto-update requires valid signatures. And you need to run the blockmap command to get those signatures. But as soon as you run that command, it will modify the .zip file and "corrupt" it on Catalina.

The solution seems to be to have users download the .dmg from your website (as opposed to a zip), and have the app use the .zip for auto-update.

[semireg]

See also https://github.com/develar/app-builder/issues/24

[vicatcu]

I don't know how to get this to work. I scp'd the App as a directory over to a linux machine and zipped it there, then sent that zip to the internet, downloaded it on my Mac where I built it, and when I launch it I get a dialog telling me "Your App Name" can't be opened because the identity of the developer cannot be confirmed... Your security preferences all installation of only apps from the App Store and identified developers." Then I can circumvent that through my system settings, but that's not really an acceptable user experience for people downloading the app from my website. Should I just be uploading the DMG artifact in the dist folder instead of the zip or what?

[jthrilly]

I don't know how to get this to work. I scp'd the App as a directory over to a linux machine and zipped it there, then sent that zip to the internet, downloaded it on my Mac where I built it, and when I launch it I get a dialog telling me "Your App Name" can't be opened because the identity of the developer cannot be confirmed... Your security preferences all installation of only apps from the App Store and identified developers." Then I can circumvent that through my system settings, but that's not really an acceptable user experience for people downloading the app from my website. Should I just be uploading the DMG artifact in the dist folder instead of the zip or what?

This sounds like your app isn't signed, which would be a different issue to this one.

[oskarhane]

@mobitar

The solution seems to be to have users download the .dmg from your website (as opposed to a zip), and have the app use the .zip for auto-update.

Do the zip (or .app inside it) need to be notarized as well as signed? I have a working (signed + notarized) dmg now which I offer as downloads. For the auto update I plan to offer the zipped app, but I currently only sign it, not notarize. Would that put me in trouble when updating the app via electron-updater?

[pashvin]

This thread is diverted a lot from the original issue. This was created for the ZIP artifact comes out of the box by just simply adding option in package.json to generate ZIP and that file does not work in Catalina. Can we fix or find fix for that first? I know if you host ZIP and any DMG file on web url and download from there , then there are other issue where Mac OS does not trust that package but in my case I am not hosting or downloading. I am directly unziping on build machine and trying to run and that does not work first place.

[moughxyz]

Here's what finally worked for me:

First prepare .zip file:

1. Open dist/mac
2. Right click .app file and compress
3. Move .zip file to ~/Desktop (or wherever)

Then:

1. Clone https://github.com/develar/app-builder
2. cd into directory, then go build
3. Run ./app-builder blockmap -i ~/Desktop/myapp.app.zip -o ~/Desktop/throwaway.zip
4. Copy the output sha512 and size params into yourapp/dist/latest-mac.yml.
5. Upload latest-mac.yml and ~/Desktop/myapp.app.zip to GitHub (or other CDN).

The important part here is the -o (output) arg in the app-builder command. This prevents app-builder from directly modifying the input file (which is what's causing the problems).

Both auto-update and direct zip extraction worked for me on Catalina with this method.

[pashvin]

So that is the fix (create a zip artifact before bundling to dmg. Use the same .app to zip) and we all know these manual steps works but we need to fix electron builder so no one need manual steps we are talking about these manual step over and over but it is time to fix the electron builder.

[sidneys]

Here's what finally worked for me:

First prepare .zip file:

1. Open `dist/mac`

2. Right click .app file and compress

3. Move .zip file to ~/Desktop (or wherever)

Then:

1. Clone https://github.com/develar/app-builder

2. `cd` into directory, then `go build`

3. Run `./app-builder blockmap -i ~/Desktop/myapp.app.zip -o ~/Desktop/throwaway.zip`

4. Copy the output `sha512` and `size` params into `yourapp/dist/latest-mac.yml`.

5. Upload `latest-mac.yml` and `~/Desktop/myapp.app.zip` to GitHub (or other CDN).

The important part here is the -o (output) arg in the app-builder command. This prevents app-builder from directly modifying the input file (which is what's causing the problems).

Both auto-update and direct zip extraction worked for me on Catalina with this method.

This works as an interim solution - many thanks to you.

[LabhanshAgrawal]

Is there any update on this? The workaround is ok for now, but would prefer to have a proper fix.

[Aarbel]

Same issue there, looking for a good workaround

[matheuss]

We're seeing the same for https://hyper.is https://getkap.co 🤕

[jwheare]

This is blocking a release for https://github.com/irccloud/irccloud-desktop

[do-web]

Here's what finally worked for me:

First prepare .zip file:

1. Open dist/mac
2. Right click .app file and compress
3. Move .zip file to ~/Desktop (or wherever)

Then:

1. Clone https://github.com/develar/app-builder
2. cd into directory, then go build
3. Run ./app-builder blockmap -i ~/Desktop/myapp.app.zip -o ~/Desktop/throwaway.zip
4. Copy the output sha512 and size params into yourapp/dist/latest-mac.yml.
5. Upload latest-mac.yml and ~/Desktop/myapp.app.zip to GitHub (or other CDN).

The important part here is the -o (output) arg in the app-builder command. This prevents app-builder from directly modifying the input file (which is what's causing the problems).

Both auto-update and direct zip extraction worked for me on Catalina with this method.

Not working for me, i got an error in the auto updater "undefined".... @mobitar any idea?

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jwheare]

Yes this is still very relevant. It requires changes to the zip step, or at the least some hooks for us to override that step with an appropriate workaround.

[philippkuehn]

Oh man these bots. Yeah it’s relevant as long it’s not fixed 👀

[tbuteler]

I tried all workarounds listed here and they didn't help in my case. No matter how I built the ZIP file, once I uploaded it to GitHub and downloaded it with Chrome, it would fail to open (inspecting the extracted application with codesign said that code signing didn't happen, but my release pipeline verifies both signature and notarization and confirmed all was well). Downloading the same ZIP file with Safari, on the other hand, would work as expected.

I'm on macOS 10.15.4 Catalina. Tried creating builds with electron-builder 22.5.1 and 21.2.0, both yielded the same results above.

I've retroactively added DMG releases on a couple of older versions of my app and can confirm that not only applications extracted from DMGs work fine, but auto-updating will work too, without any of the workarounds listed here (i.e. electron-builder updater can extract the app from that same ZIP that Chrome can't touch and upgrade locally without issues).

I'll just permanently move away from offering ZIP files for users to download on Mac, and use DMGs instead. Seems much more practical than waiting around for Apple to fix this issue.

Thanks to all who posted their findings here, I really appreciate it.

[yanlee26]

Here's what finally worked for me: First prepare .zip file:

1. Open `dist/mac`

2. Right click .app file and compress

3. Move .zip file to ~/Desktop (or wherever)

Then:

1. Clone https://github.com/develar/app-builder

2. `cd` into directory, then `go build`

3. Run `./app-builder blockmap -i ~/Desktop/myapp.app.zip -o ~/Desktop/throwaway.zip`

4. Copy the output `sha512` and `size` params into `yourapp/dist/latest-mac.yml`.

5. Upload `latest-mac.yml` and `~/Desktop/myapp.app.zip` to GitHub (or other CDN).

The important part here is the -o (output) arg in the app-builder command. This prevents app-builder from directly modifying the input file (which is what's causing the problems). Both auto-update and direct zip extraction worked for me on Catalina with this method.

This works as an interim solution - many thanks to you.

still not work for me...

{
  constructor: 'Error',
  code: 2,
  domain: 'SQRLUpdaterErrorDomain',
  stack: 'Error: Could not locate update bundle for com.github.Electron within file:///Users/elliotyan/Library/Caches/com.github.Electron.ShipIt/update.nxcQidV/'

[jetlej]

Any updates?

[georgevs]

Electron-builder Version: 22.4.0 macOS version: Catalina 10.15.4 Node version: v12.16.1

It seems like the attributes of the symbolic links in the Frameworks subfolder in the app bundle in both zip and tar.bz2 are lost and the files appear to the OS as regular files.

> ls -la ./dist/zip/Electron.app/Contents/Frameworks/Electron\ Framework.framework
-rw-rw-r--   1 georges  ...   35 May 15 18:49 Electron Framework
-rw-rw-r--   1 georges  ...  26 May 15 18:49 Libraries
-rw-rw-r--   1 georges  ...   26 May 15 18:49 Resources
drwxrwxr-x   4 georges  ...  128 May 15 18:49 Versions

> ls -la ./dist/mac/Electron.app/Contents/Frameworks/Electron\ Framework.framework
lrwxr-xr-x   1 georges  ...   35 May 15 18:49 Electron Framework -> Versions/Current/Electron Framework
lrwxr-xr-x   1 georges  ...   26 May 15 18:49 Libraries -> Versions/Current/Libraries
lrwxr-xr-x   1 georges  ...   26 May 15 18:49 Resources -> Versions/Current/Resources
drwxr-xr-x   4 georges  ...  128 May 15 18:49 Versions

Adding/removing notarization won't fix the links.

[georgevs]

@MehediH I am not convinced that's the macOS only to blame. Please note that if I manually tar/bzip2 the app in dist/mac everything looks and works fine with the generated tar.bz2 archive, and still the attributes are lost with the electron-builder generated tar.bz2:

... in ./MyApp/dist/mac ...
$ FN=MyApp ; /usr/bin/tar -cf ${FN}.tar ${FN}.app && /usr/bin/bzip2 -fz9 ${FN}.tar

... in ./MyApp/dist ...
$ tar tvf MyApp-1.0.0-mac.tar.bz2 | grep Electron\ Framework.framework/Libraries
-rwxrwxrwx  0 0      0          26 May 18 09:17 MyApp.app/Contents/Frameworks/Electron Framework.framework/Libraries

$ tar tvf mac/MyApp.tar.bz2 | grep Electron\ Framework.framework/Libraries
lrwxr-xr-x  0 georges ...      0 May 18 09:17 MyApp.app/Contents/Frameworks/Electron Framework.framework/Libraries -> Versions/Current/Libraries

When it comes to the .tar.bz2 archive, it seems like the issue is with the 7za tool. The Electorn-builder calls 7za with the following commands to archive and then compress:

$ 7za a -bd MyApp.tar MyApp.app
$ 7za a -bd -mx=9 MyApp.tar.bz2 MyApp.tar

If one lists the tar file you'll see the links are gone:

$ 7za l MyApp.tar |  grep Electron\ Framework.framework/Libraries
2020-05-18 14:34:31 .....           26          512  MyApp.app/Contents/Frameworks/Electron Framework.framework/Libraries

I tried passing -snl or -snh which the 7za documents as "preserving" the symbolic links and hardware link but those didn't help ... links are still written as flat files in the .tar file.

$ 7za a -bd -snl MyApp.tar MyApp.app

$ 7za l MyApp.tar |  grep Electron\ Framework.framework/Libraries
2020-05-18 14:34:31 .....           26          512  MyApp.app/Contents/Frameworks/Electron Framework.framework/Libraries

[kamalbennani]

This is a very strange issue and I'll mention my findings because I haven't seen it mentioned here.

I had multiple Catalina users report "The application Label LIVE can't be opened." I downloaded and the app worked fine on Catalina. URL for reference and public reproduction: http://label.live/download.

I finally screen-shared (via Zoom) with a user and sure enough, the download app didn't work. They were using Chrome and the zip file was being decompressed by Archive Utility. I had the user download the same zip using Safari and presto, the decompressed app launched no problem. I have given this advice to other users with varying success. I believe that Safari users must have "Open safe files after downloading" checked. If not, then the Archive Utility is launched to unzip - causing the issue.

In all of my own tests I was decompressing with Safari's built-in unzipper (whatever that is)... can anyone confirm this issue with their builds? I'm skeptical that I'm the only one to notice this behavior...

Thank you, man, for this finding 💪

[alexandreroche]

Would love a fix here!