Mac codesigning and notarization

[lazerwalker]

I have a valid dev account, just need to make time to test this. This will likely shake out issues with login flow -- e.g. how do we handle 2FA keys?

[IanBellomy]

FWIW, I can confirm this isn't working out of the box, at least following the instructions as I understood them. Tried with secret vars for an app developer account+PW (as described); but at minimum an app specific PW was needed (https://support.apple.com/en-us/HT204397). Using that cashed out with another problem though:

...
- Packaging Application
WARNING: Code sign failed; please retry manually. Error: No identity found for signing.

An unhandled rejection has occurred inside Forge:
Error: Failed to upload app to Apple's notarization servers
...

Last I signed an OS X app for distribution outside of the App Store I think I needed a profile on the system from which I requested the signing, or at least an locally installed cert of some kind... but it's been a minute.

[IanBellomy]

Got it working but there's a laundry list...

As mentioned, the user's dev account password should be an app-specific password. This'll need generated per (https://support.apple.com/en-us/HT204397) if they haven't done so.

User will need to create a 'Developer ID application' cert from Apple's developer tools site,
download it,
load it into keychain
then export as .p12 with a password.

The password needs to go in the repository secret CERTIFICATE_PASSWORD
The base64 encoded contents of the .p12 cert needs placed in CERTIFICATE_OSX_APPLICATION.

The electron-wrapper-template needs an entitlements.plist file.

That plist should probably look something like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
	<key>com.apple.security.cs.allow-jit</key>
	<true/>
	<key>com.apple.security.cs.disable-library-validation</key>
	<true/>
	<key>com.apple.security.cs.disable-executable-page-protection</key>
	<true/>
	<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
	<true/>
    </dict>
</plist>

The disable-library-validation may be necessary for Apple to code sign at all. allow-jit and allow-unsigned-executable-memory may be necessary for the app to run after being signed.

The config for electron-wrapper-template needs updated to point to it.
(I think this is correct, but I wasn't super sure what the folder structure looks like when during the build process so I also dropped the plist in my own project src 😬...)

osxSign: {             
   entitlements: 'src/entitlements.plist',            
   'entitlements-inherit': 'src/entitlements.plist',            
   ...

Also, the user's developer id application field also needs set in there. It includes an alphanumeric portion that I only know how to look up by running security find-identity in the terminal (of a system that has the cert installed I think) and manually copying it from the listed valid identity.

In twine-app-builder/.github/workflows/main.yml the end of the "Add MacOS certs" section, should probably be

rm -fr *.p12

not

rm -fr *.p12chmod +x add-osx-cert.sh && ./add-osx-cert.sh

And.... I think "that's it".

[lazerwalker]

Thanks so much for this, that's super helpful! Will work on folding as much as I can into the template and the rest into the instructions :)

[lazerwalker]

I'm working on this right now!

The default suggested workflow is going to be one that uses Fastlane to automatically manage certificate generation on GitHub Actions (i.e. you don't need your own Mac hardware to do the CSR dance), but I am going to include manual instructions that look a lot like this guidance.

@IanBellomy if it's okay with you, I'll ping you when that's ready to get a second set of eyes on my instructions :)

[IanBellomy]

Sure thing, though I'm the opposite of an expert on this stuff :|

Also, it looks like improvements to notarization have been announced at the current ongoing wwdc: https://developer.apple.com/videos/play/wwdc2021/10261/

[lazerwalker]

Ah, thanks for that, I hadn't seen the changes! For better or for worse they won't affect this tool for now (I'm entirely relying on upstream tools to provide automated notarization, so I'll just be waiting for those tools to update to the new CLI tool/workflow), but awesome to know.

[lazerwalker]

I've updated the README with instructions for notarization! @IanBellomy LMK if this seems to vastly differ from your experience (although I was able to successfully run through that flow myself)

Splitting out #30 and #31 as the two remaining tasks here, and closing this issue for now.