Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS Hardened Runtime Fails - $250 Bounty #4693

Closed
GitBreezePaul opened this issue Feb 21, 2020 · 4 comments
Closed

macOS Hardened Runtime Fails - $250 Bounty #4693

GitBreezePaul opened this issue Feb 21, 2020 · 4 comments

Comments

@GitBreezePaul
Copy link

  • Version: electron-builder 22.3.2
  • Version: electron-updater 4.2.0

  • macOS SDK: 10.15 (verified using xcodebuild -showsdks)

  • Target: macOS (not Mac Application Store, just Mac)

We have a project that was working perfectly on macOS, signed and notarised, using the above technologies. Since we are not releasing via MAS, just on Mac, we didn't need sandboxing or hardening.

Then Apple decreed we needed to do hardened runtime just to get signed and notarised from February. This was turned on using the below configurations. We do not need sandboxing, just the hardened runtime. The signing and notarising still works fine.

But despite trying dozens of entitlement variations, nothing is working. Electron never appears, and the crash dump shows it gets as far as starting V8, and then a memory problem occurs, according to Apple support. We have tested out the end result on macOS using Taccy which has confirmed that changes to the entitlements file do get through to the signed software on the Mac.

There are two curious points. One is a side issue of no great importance, that Taccy insists the camera and microphone are needed, which they aren't. This doesn't seem to be due to a dependency, because even with no code and no dependencies, this is requested. Is it something inside electron / electron-builder / electron-updater? This isn't the big point though.

More importantly, our build machine is 10.15, but looking at Taccy shows that it claims that our app has been built with macOS SDK10.13 which of course may not be modern enough. Apple states we should be using a build machine with macOS 10.13.6 (High Sierra), and its SDK might well be only 10.13. But given that the build machine is using 10.15, as verified using xcodebuild -showsdks at build time, where is Taccy getting the 10.13 information? Is there something in electron-builder or electron-updater that is using an old SDK? Or is Taccy wrong?

This problem affects us even when we strip out all of our code! An empty page saying 'hello' in Electron fails. With or without entitlementsInherit, with some or all hardened runtime entitlements, and even with some sandboxing ones thrown in (to provide the microphone entitlement). No variation works.

If you can solve this, we'll donate $250!

Main config

 config.mac = {
	icon: '../app/electron/static/icons/Oscar.icns',
	category: 'public.app-category.developer-tools',
	target: 'dmg',
	type: 'distribution',
	hardenedRuntime: true,
	entitlements: './config/packaging/macosEntitlements.plist',
	entitlementsInherit: './config/packaging/macosEntitlements.plist',
	gatekeeperAssess: false,
 }

Entitlements

  <dict>
	 <key>com.apple.security.cs.allow-jit</key>
	 <true/>
	 <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	 <true/>
	 <key>com.apple.security.cs.allow-dyld-environment-variables</key>
	 <true/>
	 <key>com.apple.security.device.camera</key>
	 <true/>
	 <key>com.apple.security.device.audio-input</key>
	 <true/>
	 <key>com.apple.security.device.microphone</key>
	 <true/>
	 <key>com.apple.security.network.server</key>
	 <true/>
	 <key>com.apple.security.network.client</key>
	 <true/>
	 <key>com.apple.security.files.user-selected.read-only</key>
	 <true/>
	 <key>com.apple.security.files.user-selected.read-write</key>
	 <true/>
  </dict>
@kzimny
Copy link

kzimny commented Feb 26, 2020

did you try with one of the boilerplates? https://www.electron.build/#boilerplates

@GitBreezePaul
Copy link
Author

Thanks, but the point is that our app was working like a charm on macOS, with code signing, notarisation and all. It was hardening that killed it. Going back to square one with a boilerplate won't make our application work, sadly.

@kzimny
Copy link

kzimny commented Feb 26, 2020

Yes, you're right. But, how do you want to solve your problem without testing step by step? If the app was working fine before February, the problem can be caused by hardened runtime. I would recommend to delete all your business code first (is not a joke!). Make sure your app looks like a boilerplate and try to build with hardenedRuntime=true. If your "boilerplate" app will start and work, add your business code step by step back and test when the build fails. If you already tried everything, this could be the only way to to go...

@GitBreezePaul
Copy link
Author

Finally solved. In depth description here:

#4040 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants