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: 773
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: 773
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: 773
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: 773
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.
User avatar
richmond62
Posts: 699
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Code-Signing (again)

Post by richmond62 »

As code-signing seems a bit like Apple getting into totalitarian control mode for the 95th time
I would recommend using some type of 'player' that can run stacks: or, as frankly, anything authored
on OXT will be open source, not bothering with stand alones at all, but just issuing the stacks with the
IDE . . .

OK, OK, I know that this will make some hackles rise, but it is something that needs to de addressed and discussed.
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 773
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Code-Signing (again)

Post by OpenXTalkPaul »

richmond62 wrote: Wed Dec 21, 2022 3:28 pm As code-signing seems a bit like Apple getting into totalitarian control mode for the 95th time
I would recommend using some type of 'player' that can run stacks: or, as frankly, anything authored
on OXT will be open source, not bothering with stand alones at all, but just issuing the stacks with the
IDE . . .

OK, OK, I know that this will make some hackles rise, but it is something that needs to de addressed and discussed.
We just got a new TV for Christmas that has Android 10 built-in to it so I'm going to want to mess around with building apps to run on that.

I like being able to build standalones, in fact I've been thinking of OXT going the exact opposite direction by eventually ADDING more deployment options (or re-adding old ones back in), some of which (such as OpenXION-native standalone) may not be bound by the same license (OpenXION has a more libre LGPL license).

The case already with Standalone apps is that certain deploy options may not have the same feature compatibility level others, 32bit vs 64bit for example, so why not take that further and allow for 'back-porting' standalones for systems that had support for them dropped by LC, such as PowerPC. The way it works currently is you get a warning messages if you're building an app where the features may not work with the engine you're deploying with. So for example you may have to downsave the Stack as very.7 stack format which doesn't support Widgets and Extensions. It's basically been left up up to the author to know what's supported on which engines (but a guide to back-porting could be developed).
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest