screen recording permission dialog

[neville]

next problem from my test stack

As soon as I start to drag an image - the issue is no doubt caused by my call to

export snapshot

I get a system dialog saying I must allow Screen and Audio recording. This is on macOS Ventura. I gather this was encountered before when implementing paint tools and eye dropper, but I don't know what was the resolution there?

a. the dialog may be spurious, as drag-and-drop works fine if I just cancel, for the life of the IDE session.

b. if I do try to add OpenXTalk Lite to the allowed apps in Privacy and Security/Screen Recording and Audio nothing happens, it doesn't get added and I get the annoying dialog next time I launch my stack

c. I can however add OpenXTalk DPE to the the allowed apps list. And I don't get the system dialog at all with OxT DPE. Which seems to indicate there may be an entry missing from the Mac bundle plist for Lite.

[tperry2x]

Yes, probably there are numerous issues with the plist file under MacOS.
I don't ever see any of these as my test Macs are only capable of running MacOS 10.15 Catalina. Nothing higher.

The only other one I can occasionally borrow isn't even mine, and is running MacOS 12.7.4 - but I don't get the error on there either.

I do know however, that changing the plist breaks codesigning.
I'm looking for a mac developer for OXT-Lite!

In all seriousness, and with absolutely no sarcasm intended or implied, would you like to take up this role?

[neville]

would you like to take up this role?

I rather think my days of Mac development are probably over (probably). I gave up my Apple (and IOS) developer membership and retired from that life just as Swift was becoming mandatory, so I only have a rudimentary knowledge of Swift. And we have talked about my experience with Github !

I would expect there would be an influx of people to OxT from you know where - in fact some of them are already here lurking --- yes you, I see you, could you take on the role? Of course most of them may be like me retiree hobbyists just wanting to dabble.

AS for code signing, what about the tools that people like Mathias on the other side made available?

Neville

[FourthWorld]

Swift is becoming mandatory?

[neville]

Oh, isn't it? I thought Objective-c was deprecated, and that Apple would only accept apps for the store compiled in Swift? Are they really maintaining the Obj-C codebase for ARM development? Good on them, but it surely can't last.

Neville

[FourthWorld]

Apple briefly tried to control the provenance of software with their radical change to iOS SDK v4 EULA Section 3.3.1. Quite an uproar at the time. They quietly backpedalled less than a year later after the game industry and everyone else reminded them it was insane.

In the years since we've seen iOS apps written in many languages, even LiveCode.

[richmond62]

I develop an app for Linux, Windows, and Macintosh: it runs on all those platforms: no stapling, horse-shoeing, or anything else: whether Apple 'support' a development environment is neither here nor there: whether something developed with a certain development environment runs on MacOS, or any other platform is what matters.

Most of my LEGO collection is echt LEGO, but the LEGO-compatible blocks the BILLA supermarkets were giving away in Bulgaria about 5 years ago fit right in: and I for one am not going to ask "Mrs LEGO" permission to use them.

[richmond62]

Oddly enough with OXT Lite I have performed an 'export snapshot' 4 times and never experienced any dialogues:

MacOS 12 & MacOS 14-15

[neville]

Oddly enough with OXT Lite I have performed an 'export snapshot' 4 times and never experienced any dialogues:

That is interesting! So I wonder what is causing it here in Ventura (macOS 13, but I'd expect the same in 14) The subsequent drag of the exported image shouldn't require "screen recording". Very mysterious. I had never seen the dialog in any other app. Is OpenXTalk Lite listed in your Privacy and Security/Screen Recording list of authorised apps? As I mentioned, I couldn't get my Mac to accept the listing when I click the + button.

I believe I saw in the forum OxT had earlier experiences with this dialog (with the eye dropper tool I believe?). So what was the resolution there??

I just compared the plists for Lite and DPE, they are vastly different - presumably lots inherited from LCE and stripped from Lite but lots of requested permissions look essential and I think should be there. The only one that I can see that relates to the Screen Recording and Audio case is

<key>NSMicrophoneUsageDescription</key>
<string>Needed to record sound</string>

Finally Tom are you using Matthias Rebbe's mrSignNotarizeHelper stack? User's in the other place swear by it.

[Richard: Shows how long I have been out of the Xcode scene. Actually I had stupidly assumed the Mac LiveCode engine was written in Swift, but I see it is c++, of course multiple source languages would be impossible to manage]

[tperry2x]

presumably lots inherited from LCE and stripped from Lite but lots of requested permissions look essential and I think should be there. The only one that I can see that relates to the Screen Recording and Audio case is

<key>NSMicrophoneUsageDescription</key>
<string>Needed to record sound</string>

Finally Tom are you using Matthias Rebbe's mrSignNotarizeHelper stack? User's in the other place swear by it.

I can't remember stripping much out of the plist, but if there's stuff missing from Lite's plist I suppose I must have. Either that or it was added to DPE at a later stage?

I've never heard of "Matthias Rebbe's mrSignNotarizeHelper stack", so I went digging for it.

mrSignNotarizeHelperV4_Xcode14.livecode

(164.74 KiB) Downloaded 42 times

I don't really know what I'm looking at.

what-is.png (92.13 KiB) Viewed 1658 times

Other than noticing that it throws an error when I try to close the stack:

error.png (4.88 KiB) Viewed 1658 times

I had got cheesed off regarding the lack of useable information, and lack of straightforward information about codesigning. So much so that I ended up making a stack to do self-signed codesigning for me.
This is great, and is working, and is why you can now open OXT Lite without those annoying "application is damaged" under MacOS errors - but of course, this doesn't make a plist for me.

How does one construct those plists (in human-readable terms?)
A stack that generates these would be very welcome, as when you get into 'how do I implement this' - there seems to be a lot of chaff to filter out and no straightforward answers.

[neville]

Sorry, Tom , I've never used the code signing stack myself, but there is supposed to be documentation somewhere.

For plists, Xcode gives a human readable form, but it is just XML (I think?)

Neville

[tperry2x]

Don't be sorry - no apologies necessary. If anything, I'll point the finger at Apple for not providing a clear guide on how plists are written, what needs to be included and instead making it an obfusicated process.

What I'm thinking of is a stack with a load of checkboxes. Called pList maker (Or perhaps "Taking the pList" ).
A load of checkboxes down the side that I want the application under MacOS to be able to do (camera, file permissions etc)...
Then click a 'generate' button, and for it to put the plist text into a field.
That would be good.

However, something else comes to mind. If all this 'sandboxing' is supposed to in some way enhance the security of MacOS... but it's ultimately just changing lines of a glorified text file to get around these security prompts? (Doesn't seem very 'secure') - or perhaps it's secure in as much as, nobody knows how to create new ones easily - so it's only secure because of that?

Don't know, but as I was going on about - I need someone to take up the reigns of OXT Lite on MacOS, as the platform is quite unusable now (as far as I'm concerned) with all these 'features'.

[tperry2x]

Something like this is what I was thinking. There's probably more that needs to go into it though.
Hopefully Paul can tell me what else needs to be added:

screenshot.png (301.06 KiB) Viewed 1606 times

MacOS-plist-Maker.oxtstack

(6 KiB) Downloaded 39 times

(I'll need to make the buttons conditional of course). At the moment, they were just a reminder for me. I don't think I've missed any permissions

[OpenXTalkPaul]

Objective-c was deprecated, and that Apple would only accept apps for the store compiled in Swift? Are they really maintaining the Obj-C codebase for ARM development?

I think Apple is not likely to go 'Swift only' anytime soon. Although they do seem to want to move away from old Cocoa 'NS' APIs (originally for NeXT step) to newer APIs developed for iOS. The underlying stuff used to implement these things in macOS are still C/Objective C based, though there may be Swift equivalent syntax, the Objective C stuff and C 'Core' APIs are still at the core. Almost all macOS APIs currently on Apple's documentation site have both Objective C & Swift versions of the Docs. That's not to say Apple won't someday drop Objective C, just that I don't think it will be soon.

[OpenXTalkPaul]

True, you can read/write to the 'non-binary format' .plist files as XML-text, but I wouldn't recommend it since it's rather hacky and some .plists are dynamically generated with unique names so it may be hard to even find the particular .plist one would want to edit, and at any rate that won't help with the binary format plist can come in.

.PLIST is a NeXT step format based on XML, but not quite normal XML. Its field tags include variable data types (Like Boolean, String, Dictionary, etc.). It's been used extensivily in NeXTStep/OpenStep up to and including Apple's present day macOS. There are Objective C APIs for reading plists and transforming the data to NSDictionary Arrays and such.
I could probably write an Extension that uses Apples APIs to transform plists data into the associative array format we can use more easily with xTalk script.

There's also some good tools that exist for editing plist (PlistEdit Pro, ProperTree).

[OpenXTalkPaul]

Hopefully Paul can tell me what else needs to be added:

That looks like the hardware access provisions that I put into my provisioning file as well, it might even be more than I've got in mine.

The problem I believe is something not being fully compatible in the engine source in regards to the macOS current 'user hardware access permissions' granting mechanism in newer macOS. You can give it the 'Screen Capture' permissions to the app and it still may pop up that alert when you use certain syntax like 'Snapshot' on certain macOS versions. In contrast, if you use newer APIs (for example AVAudioRecorder instead of older the NSSoundRecorder) it presents the expected Dialog only when the App requests the permission for the first time. Permission being granted, thereafter the dialog should not appear again. The Snapshot syntax seems to ask permission once per app session regardless of the app's permissions provisioning file including "Screen Capture", which seems like an 'engine needs updating' sort of bug.

[OpenXTalkPaul]

Hopefully Paul can tell me what else needs to be added:

That looks like the hardware access provisions that I put into my provisioning file as well, it might even be more than I've got in mine.

Actually I think I gave mine permissions provisions related to being a development tool as well, the thinking being that going forward the IDE may need the same permissions that something like AppleScript Script Editor (which can also build standalone apps) has assigned to it. That one might only be needed for executing external code, that is code that exists outside of the Application's bundle, such as Application with 'Plug-Ins' or app 'Extensions'

[OpenXTalkPaul]

a. the dialog may be spurious, as drag-and-drop works fine if I just cancel, for the life of the IDE session.

b. if I do try to add OpenXTalk Lite to the allowed apps in Privacy and Security/Screen Recording and Audio nothing happens, it doesn't get added and I get the annoying dialog next time I launch my stack

c. I can however add OpenXTalk DPE to the the allowed apps list. And I don't get the system dialog at all with OxT DPE. Which seems to indicate there may be an entry missing from the Mac bundle plist for Lite.

Yes, I think this is correct on all accounts.
This is a bug in 'export snapshot' on newer macOS related to user granted hardware permissions.
It should not happen once per app session, should only ask until the app is granted permissions (which should auto-add it to that System Prefs Panel).
Tom you should probably match (change to 'Lite') the macOS specific files in my repo:
https://github.com/OpenXTalk-org/OpenXt ... Info.plist

I'd post my provisioning file too but I can't seem to locate it at the moment.
That is used in generating the _CodeSignature (IIRC) which is here:
https://github.com/OpenXTalk-org/OpenXt ... eResources

[tperry2x]

Tom you should probably match (change to 'Lite') the macOS specific files in my repo:
https://github.com/OpenXTalk-org/OpenXt ... Info.plist

I'd post my provisioning file too but I can't seem to locate it at the moment.

To deal with both issues at the same time (for the purposes of testing), I took your entire RC4 application and navigated to Contents > Tools
As I know that everything in this "Tools" folder I can safely swap without affecting codesigning, I deleted everything in this folder and copied the bits over from my Lite version. So then what I have is a codesigned version of OpenXTalk using your provisioning and plist, but with the bits that make up my lite version.

This runs fine.
Things to note: I do get the initial dialog asking for permissions on first launch (see last frame of screenshot where this is being recorded in system preferences > privacy > automation

screens.gif (767.91 KiB) Viewed 1540 times

My next question will be, can I replace the icon and change the name without breaking codesigning (probably not). - You can also see my 'Lite' version would have also asked for permission in the same way, which I would have granted at some stage too...

There's a screenshot hanging around somewhere, let me locate it...
edit: here we are. I remember MacOS 12 asking the same thing at some stage on 'Lite' too - so I can confirm both versions do ask for permissions:

OXT Lite 1.05 MacOS 12.7 pic-a.png (503.97 KiB) Viewed 1538 times

[OpenXTalkPaul]

can I replace the icon and change the name without breaking codesigning (probably not)

I'm not sure. I think I initially I did much the same, using the LC CE codesign file but updated any name / identifier references it contained. At one point I thought adding microphone access provision there and in the apps info.plist would be enough to get the dialog to appear asking to allow mergRecord external have permission to use the microphone, but it didn't work. Later I realized I needed to stripped away the signing of that binary for the mergRecord external, in order to get the dialog to appear. Then I think I stripped ALL binaries of the old macOS code-signing and subsequently re-signed (which I had to reboot with gatekeeper /sip turn off in order to do, IIRC) with my own new provision file. Got it working. ***

I thought that the codesign file and the signing attached to the executable binaries had to be in a certain state (matching hash?), but not sure if there's any name/identifier mismatch that would stop it working, like if one used from codesig from another app (in fact on macOS this was an effective work-around for installing user apps while not having Admin privileges on a Mac, not sure if that trick still works). Anyway there's definitely some difference between the app wrappings of OXT DPE vs OXT Lite in that Lite doesn't show when attempting to add it manually I the System Prefs Panel, as Neville mentioned. Trying to narrow it down.

*** (Alternatively, I've since wrote an Extension that uses Apple's newer AVAudioRecorder instead of mergeRecord and that behaves as expected, asking the user to grant microphone permission)