Code-Signing (again)

Organizing tasks to work on, New Features Ideas, Building LCS & LCB Libraries & Widgets, Redecorating and Modifying the IDE, Hacking / Editing Tools, Compiling the Engine from Source, etc.
Post Reply
User avatar
OpenXTalkPaul
Posts: 589
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Code-Signing (again)

Post by OpenXTalkPaul »

I wasn't real worried about re-codesigning OXT for macOS... until I realized certain things don't work properly in newer macOS versions without a valid signature that includes any entitlements that may be needed such as hardware access (microphone, camera) permissions. I realized this because the already outdated MergMicrophone external fails (worse, it doesn't give any helpful errors when it does fail) does not record under OXT but works on LCC. There's also a 9.x release note about Audio Record not working in Mac 64bit Standalones, which I'm thinking may be related. I believe the problem is the Mac "hardened runtime" in late versions of 10.14 on. In BigSur, and particularly on the new M1 Macs, the user must be asked and then must grant permission to access the microphone (or camera, or to do snapshots, etc.). If macOS doesn't see the entitlement in binaries code signature (or "code requirements" or whatever) it may never ask the user to grant the permission and then just fails to record. So I guess I'll be re-signing the IDE app bundle with my own dev signature.

BTW, I spent a little bit of time trying to wrap AVAudioRecorder API as a replacement for mergMicrophone on macOS, but I may just try to wrap some cross-platform audio record library, three OSes with one stone, ya know?

Anyway the bottom line is, going forward microphone permission will always be needed to be granted to an app that needs it in new versions of macOS.
User avatar
OpenXTalkPaul
Posts: 589
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Code-Signing (again)

Post by OpenXTalkPaul »

FYI:
To see a digital signature use this command line:
codesign -dr - "path/to/the/binary"

To remove the digital signature, use this (undocumented?) command line:
codesign --remove-signature "path/to/the/binary"

Once I used that to make the IDE binaries unsigned, then OXT asked me for permissions to use the microphone and I was able to record.
User avatar
OpenXTalkPaul
Posts: 589
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Code-Signing (again)

Post by OpenXTalkPaul »

So I've changed the reverse domain identifier I'm using from "org.oxt..." to "org.openxtalk...." for all things getting integrated into the OXT IDE...

I needed to redo some things on macOS, specifically the info.plist and code signature and entitlements, which go hand in hand nowdays with sandboxed apps and more and more "hardening" of the runtime. I wound up resigning the binaries with a OpenXTalk.org certificate, which is good because I wasn't sure that I could without recompiling binaries.

These changes were needed in order to get the IDE to ask for access permissions which it needs. This is more than accessing the microphone or camera, this effects things like revCopy on the Mac which uses AppleScript/AppleEvent to initiate file copying, which made me realized that AppleScript had stopped working in the OXT. There are entitlements permissions that effect code execution and library loading. Now that it's signed with expanded entitlements and info.plist to match, everything seems to be working again.
User avatar
OpenXTalkPaul
Posts: 589
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Code-Signing (again)

Post by OpenXTalkPaul »

This tech note from Apple is extremely relevant:
https://developer.apple.com/library/arc ... index.html

Particularly note that if you plan to code sign, and if you use an image editor for any images that need to be in your .app bundle, or if you just browse inside the app's bundle in the Finder, it may be enough to cause this signing error which is, I believe, related to things like custom thumbnail icons generated by image editors, I'm guessing these extended attributes are some of those stored in those '._foo.file' invisible metadata files that macOS generates, the ones a lot of external MP3 players don't like? I wrote a stack that uses a shell() script to delete those.
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest