Code-Signing (again)

[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.

[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.

[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.

[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.

[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.

[OpenXTalkPaul]

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).

[tperry2x]

I guess we have accomplished quite a few things since this was published. I think you mentioned previously Paul, that you could take the 9.6.1 engines for 32bit and add these options into 9.6.3.

32bit macOs has already made a reappearance in the 9.6.1 based lite builds.

A note on codesigning. I'll check to see if I've broken it in OXT lite 0.91 Mac versions.

Am I right that to have a 'signed' app on MacOS, you have to pay for a developer certificate?
I'd assume this is per year, not a one-time thing?

Does Windows 10 / 11 insist on codesigning as strictly as it seems to be enforced on the Mac now?

Sorry for all the questions.

[OpenXTalkPaul]

I guess we have accomplished quite a few things since this was published. I think you mentioned previously Paul, that you could take the 9.6.1 engines for 32bit and add these options into 9.6.3.

32bit macOs has already made a reappearance in the 9.6.1 based lite builds.

A note on codesigning. I'll check to see if I've broken it in OXT lite 0.91 Mac versions.

Am I right that to have a 'signed' app on MacOS, you have to pay for a developer certificate?
I'd assume this is per year, not a one-time thing?

Does Windows 10 / 11 insist on codesigning as strictly as it seems to be enforced on the Mac now?

Sorry for all the questions.

Sorry I missed this, a couple of weeks ago.

I've added 32bit (and 'far') builds back into OXT DPE as well now, so the claim about macOS Lion being supported is true again.

I also have a working Builder Extension for recording with AVAudioRecorder on macOS now (done with some help from ChatGPT AI).

To have a 'signed' app on MacOS, you have to pay for a developer certificate?

NO you don't actually. You can sign for 'Development' using a free Apple Dev account (up to three apps at a time IIRC, but I need one for my iPad jb). You could also create your own ad-hoc certificate and sign with that. There may be some signing authority that is free to FOSS projects? Have to investigate that. Then there's always unsigned, but as mentioned that can cause issues with some macOS features nowadays.

I'd assume this is per year, not a one-time thing?

Yes its $99 USD per year (last I checked).

[tperry2x]

Thanks Paul, that does make sense.
I was feeling a bit despondent, truth be told, about the state of developing for the mac outside of xcode - it does feel like anyone who doesn't want to use xcode for everything may be fighting an uphill battle with Apple.

[Kdjanz]

https://www.youtube.com/watch?v=fQ9uU9RHnRM

From a recent Swift conference in Toronto Canada this summer.
At least a few people are swimming against the current.