Ignoring `node_gyp_bins` directory is not working, causes signed & notarized apps not to pass gatekeeper

[samdesota]

Preflight Checklist

• [x] I have read the contribution documentation for this project.
• [x] I agree to follow the code of conduct that this project follows, as appropriate.
• [x] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Issue Details

• Electron Packager Version: Electron Packager 17.1.1 Node v16.17.1 Host Operating system: darwin 21.6.0 (x64)
• Electron Version: 21.2.2
• Operating System: macOS 12.6 arm64

Expected Behavior

macOS's Gatekeeper / spctl doesn't like symlinks in app bundles with invalid destinations. Node-gyp creates such a sym link to the build machines python installation under node_modules, which gets bundled into your app if you're using a native module built with node-gyp.

This issue was already addressed with https://github.com/electron/electron-packager/pull/1391, however this solution is not working. Despite ignoring it, node_gyp_bins ends up in the output .app when using electron packager v17.1.1 (in my case, with electron forge v6.0.1). I also attempted to add the file / directory to the ignore option, but the file persists.

So expected behavior is that node_gyp_bins is excluded from the output

Actual Behavior

node_gyp_bins directories with the troublemaker python3 symlink is included in the output app bundle, therefore a signed & notarized app fails to pass gatekeeper.

The only workaround I've found is to delete the directory manually in the afterPrune hook.

To Reproduce

Minimal repro here: https://github.com/samdesota/electron-packager-symlink-issue

I used create-electron-app with default options to create this, and the issue persists. Used the dependency node-mac-permissions to demonstrate the issue.

[welcome[bot]]

👋 Thanks for opening your first issue here! If you have a question about using Electron Packager, read the support docs. If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. Development and issue triage is community-driven, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[erickzhao]

@samdesota Thank you for the clear issue report! In Forge, the Rebuild step happens in an afterCopy hook, so it turns out that filtering the file during the copy step doesn't actually prevent this file from being built. :(

I would hang onto that afterPrune hack for now while we find a more elegant solution.

[jagthedrummer]

@samdesota Any chance you could document your afterPrune hack as we wait for this to be fixed?

[rllola]

@jagthedrummer Maybe this article can help ? https://www.update.rocks/blog/fixing-the-python3/

[jagthedrummer]

I ended up working around it by pinning node-gyp and fsevents to non-broken versions by adding a resolutions block to my package.json that looks like this:

  "resolutions": {
    "**/**/fsevents": "^1.2.9",
    "**/**/node-gyp": "^8.4.0"
  }

[christianguevara]

@jagthedrummer I appreciate your patience with this, I know you solved it in another way, but still posting in case is useful for somebody else.

In forge.config.js

module.exports = {
  packagerConfig: {
  },
  plugins: [
  ],
  makers: [
  ],
  hooks: {
    packageAfterPrune(config, buildPath) {
      if (process.platform === 'darwin') {
        const dirs = glob.sync(
          path.join(buildPath, 'node_modules/**/node_gyp_bins'),
          {
            onlyDirectories: true,
          }
        );

        for (const directory of dirs) {
          fs.rmdirSync(directory, { recursive: true, force: true });
        }
      }
    },
  },
};

[zxffffffff]

Has a year passed, and still there's no solution?