When I disabled SIP via recovery mode, the kext could be loaded by kextload, anyway, when system restart, kext will not be loaded by kext manager like it supposed to be in Mojave and lower.
If I enabled SIP and load the kext (the kext is full functional with 10.14 -), it will show following message
Kext rejected due to system policy: <OSKext 0x7ff02df0b450 [0x7fff89d4aba0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/...
BTW, In Catalina, how user to allow a kext ? I know in 10.13, it will show on the General of Security & Privacy, in 10.14, I was using Kextdrop, anyway, kextdrop won't work with Catalina.
Found out I just need sign the kext and notarize the kext in order to get system to load it
Related
I have an application that we're developing that provides VPN System Extension for macOS. I have successfully built, signed and notarized the app.
When we install the package the user sees this popup:
The program tried to load new system extension(s). If you want to enable these extensions, open Security & Privacy System Preferences.
However when I download an existing VPN app from the macOS AppStore I see this popup when the extension is being installed:
Why am I getting the blocked popup when my app has been notarized? Is it because it's not coming from the AppStore?
As far as I'm aware, VPNs implemented via the NetworkExtension Framework don't necessarily need to be installed as System Extensions. This is probably the distinction you're running into. You can check the list of all system extensions in the system using the following Terminal command:
systemextensionsctl list
0 extension(s)
If the "Turbo VPN" extension is not listed there, it was not installed using the OSSystemExtensionManager API.
Only system extensions need to go through the System Preferences user approval process.
So I am trying to make my app work on iOS and MacOS. Which to say it does run on both. However when I submitted it to Apple, they seemed to of made it crash. Due to the following
Crashed Thread: 3 Dispatch queue: com.apple.CoreLocation.0x7fc93e530920
Now I can tell it is due to CoreLocation, But I am wondering why did it not crash on my mac when I tested it (same version) 13.15.6.
Next is how do I fix this, if I can't get the error to happen again?
Encountered this too. In my case on macOS 10.15 all ran fine, but got a crash report when the application was submitted for review, where it crashed on Big Sur (macOS 11.3) with this error.
The solution (for me) is to add the key NSLocationUsageDescription to the plist in the Mac version.
See https://developer.apple.com/forums/thread/652193 and Apple doc
I could only intermittently reproduce this error, and when it happened it happened the moment I enabled Location Services in System Preferences. I guess that is the moment that CoreLocation inspects the plist, and sometimes crashes, i.e. not always.
Addition:
For macOS 11 (Big Sur) the authorisation of access to location has changed more than described above. Depending on your needs you need to ask for access to location, as described in https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services?language=objc.
So, this is 4 possible keys and "purpose strings" for the plist, that steer the authorisation via system alerts, with the user's choice handed to you via the delegate locationManagerDidChangeAuthorization:.
Also see https://developer.apple.com/documentation/corelocation/choosing_the_location_services_authorization_to_request?language=objc
Note that location will work fine without these strings, but you will run into a rejection with the AppStore when you submit your application for review.
Also note that if your Mac has location services NOT enabled at all in
System Preferences -> Security&Privacy -> Privacy -> Location services
no system alerts will show up at all. It is assumed that if not enabled the user does not want to be bothered.
So my mac kernal_task keep using 600%++ of my CPU usage when my Mac is plugged in, and thus i decided to delete the IOPlatformPluginFamily.kext by doing these steps:
Enter Recovery Mode
Open Terminal
Disable SIP: csrutil disable
Enter Single User Mode
Delete the kext file
But will the kext file come back if i enable SIP again?
I'm currently using High Sierra but i have been doing this since Sierra
And i followed this guide https://www.davidschlachter.com/misc/kernel_task
On my Mac OS X application released on the App Store, I want to be able to use a Jack OS X audio device as an input but the device does not appear in the list returned by portaudio. When checking the logs in the console I see:
31/01/2014 10:11:35.000 kernel[0]: Sandbox: MyApp(xxx) deny network-outbound /private/tmp/jack_default_501_0
Is there some extra permission I should add to my entitlements file to be able to access this device properly? This device properly appears/works when using testing my app without the sandbox enabled.
After upgrading to Mac OS X 10.9 and running my app (which executes various AppleScripts as part of its execution) I get a dialog that the app has to be specifically enabled via the System Preferences Security/Privacy screen. So I do this and the app then functions properly.
However, when I recompile and build the app, it will no longer execute the AppleScripts and does not show the dialog. When I look in the System Preferences Security/Privacy I see that my app is still listed there but has been disabled (i.e. checkbox reset).
BY trial and error, I have found the following:
If you change the Bundle Version string in the apps info.plist and rebuild the app even without making any other changes such as code, etc this will happen; it will be disabled from accessibility.
If you make all kinds of changes to the app (code, resources, etc) but do not change the Bundle Version string in info.plist, it will still be allowed to have accessibility access.
My question is: is there a way to circumvent disabling after rebuilding?