Contribute
Register

App & Kext notarization required in 10.14.5 +

Status
Not open for further replies.

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
4,079
Motherboard
GB Z490 Vision D
CPU
i9-10850K OC @ 5.2 GHz
Graphics
RX6800-XT+UHD630
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac Pro
Mobile Phone
  1. iOS
Hi Guys,

Just wondering what (if any) the impact of the new App and Kext notarization requirement in MacOS 10.14.5 might have on the hackingtosh community ?

Have not been able to find much in the way of info on the subject but MacRumors has an arcticle on it.

My understanding is that Notarization is not the same as Apples App Review service. The Apple notarization service is a automated system that you upload your App to and it scans it for malicious content and checks for developer code-signing if it passes it then returns the App with it flagged as being notarized and the App can be distributed outside of the App Store.

If this is true then hopefully nothing will really change but it then begs the question :-

Are Apple going to completely remove the Gate Keeper Option "Allow from Anywhere" and replace it with some other setting that allows non-App store but notarized Apps to run ?

I guess time will tell ....

Cheers
Jay
 
Last edited:
Hi Guys,

Just wondering what (if any) the impact of the new App and Kext notarization requirement in MacOS 10.14.5 might have on the hackingtosh community ?

Have not been able to find much in the way of info on the subject but MacRumors has an arcticle on it.

My understanding is that Notarization is not the same as Apples App Review service. The Apple notarization service is a automated system that you upload your App to and it scans it for malicious content and checks for developer code-signing if it passes it then returns the App with it flagged as being notarized and the App can be distributed outside of the App Store.

If this is true then hopefully nothing will really change but it then begs the question :-

Are Apple going to completely remove the Gate Keeper Option "Allow from Anywhere" ?

They removed it from the Gate Keeper default preference panel a long time ago but this can be circumvented with the terminal command :-

Code:
sudo spctl --master-disable


But if they are now going to require all Apps and Kexts to be notarized in 10.14.5 and later, I wonder if that means they are going to completely disable the "Allow for Anywhere" option ?

I guess time will tell ....

Cheers
Jay

Yes, I read something similar about this development. I understood what I read to suggest that no-longer would macOS run apps that were from unidentified developers, as we can at present. Restriction sounds more likely to me than any opening-up of the system.

Rather like the 64-bit only stipulation that is coming, hopefully it will take a while to filter down. Have any beta testers noticed a difference in 10.14.5 ?

Personally I've back-tracked to High Sierra. Not any kind of solution I know, but I have an iPhone so like iTunes management, and also prefer the older Mac App Store. Unless apps stop running as they are updated for the new rules, I'm quite happy at present.
 
Hi Guys,

Just wondering what (if any) the impact of the new App and Kext notarization requirement in MacOS 10.14.5 might have on the hackintosh community ?

Have not been able to find much in the way of info on the subject but MacRumors has an article on it.

My understanding is that Notarization is not the same as Apples App Review service. The Apple notarization service is a automated system that you upload your App to and it scans it for malicious content and checks for developer code-signing if it passes it then returns the App with it flagged as being notarized and the App can be distributed outside of the App Store.

If this is true then hopefully nothing will really change but it then begs the question :-

Are Apple going to completely remove the Gate Keeper Option "Allow from Anywhere" and replace it with some other setting that allows non-App store but notarized Apps to run ?

I guess time will tell ....

Cheers
Jay

I am also watching this development with interest. Will the kexts we are using for running a hackintosh (say FakeSMC, AppleALC etc.) also be required to be notarized? Will such kexts still be available in the future?

Personally I am still running Sierra and High Sierra on my system, and have no plans to install Mojave until 10.14.6 (or whatever is the last major update of Mojave, which will be covered by this notarization requirement).
 
Any new insight on that topic ?
 
As far as I can tell there are no issues as long as you use the existing recommend Hackintosh SIP settings (BooterConfig=0x28 and CsrActiveConfig=0x67) all 3rd party apps and kexts run just fine on Catalina.

The only real stumbling block was that Catalina uses a read only System Partition for the MacOS files but thats been resolved now as Hackintool was recently updated to support a new method of installing kexts into /L/E on Catalina, the kext install guide was also updated to reflect this change.

Cheers
Jay
 
As far as I can tell there are no issues as long as you use the existing recommend Hackintosh SIP settings (BooterConfig=0x28 and CsrActiveConfig=0x67) all 3rd party apps and kexts run just fine on Catalina.

The only real stumbling block was that Catalina uses a read only System Partition for the MacOS files but thats been resolved now as Hackintool was recently updated to support a new method of installing kexts into /L/E on Catalina, the kext install guide was also updated to reflect this change.

Cheers
Jay

On the back of this - and @Jamesbond007 's post above - do these developments point towards using EFI/CLOVER/kexts/Other as a destination for hackintosh specific kexts? Given that this injects them rather than allows them to be officially cached? I understand the kernel space security aspects but just wonder if this is a way forward after notarization is implemented.

As an example, we will no-longer be able to modify AppleHDA.kext to include Realtek audio support as it will exist in a read-only area. The only likely way forward is using Lilu and AppleALC, but will they be accepted in L/E ?
 
do these developments point towards using EFI/CLOVER/kexts/Other as a destination for hackintosh specific kexts?

@UtterDisbelief,

That has nothing to do with Notarization but as far as kexts in 10.15.+ goes ...

All 3rd party Hackintosh kexts work fine in Catalina when installed /L/E ... as I mentioned in my post above, @headkaze recently added support in Hackintool so that you can install kexts into /L/E, basically you just to need mount the system partition as Read/Write and pause gate keeper. This is implemented as a single click in Hackintool's "Tool' page and is detailed in the updated kext install guide :-


If you think about it, OEM's still need to be able to install driver kexts in /L/E, Apple published the method OEM's need to use a while back and the same process can be used for Hackintosh kexts as there is really no difference other than some Hackintosh kexts are not signed but this can be over come using the recommend Hackintosh SIP settings (BooterConfig=0x28 and CsrActiveConfig=0x67).

Lilu was also updated recently so that it can still dynamically patch the kernel and kexts in memory at boot time.

So all in all nothing has changed you just need one extra mouse click in Hackintool before installing kexts.

Cheers
Jay
 
Last edited:
@UtterDisbelief,

All 3rd party Hackintosh kexts work fine in Catalina when installed /L/E ... as I mentioned in my post above, @headkaze recently added support in Hackintool so that you can install kexts into /L/E, basically you just need mount the system partition as Read/Write and pause gate keeper. This is implemented as a single click in Hackintool's "Tool' page and is detailed in the updated kext install guide :-


If you think about it, OEM's still need to be able to install driver kexts in /L/E, Apple published the method OEM's need to use a while back and the same process can be used for Hackintosh kexts as there is really no difference other than some Hackintosh kexts are not signed but this can be over come using the recommend Hackintosh SIP settings (BooterConfig=0x28 and CsrActiveConfig=0x67).

Lilu was also updated recently so that it can still dynamically patch the kernel and kexts in memory at boot time.

So all in all nothing has changed you just need one extra mouse click in Hackintool before installing kexts.

Cheers
Jay

Nice info.
Are you sure about csrActive? If you use the latest clover builds 0x03FF checks off all the boxes. I know there is one for unapproved Kexts.

Clover boot manager system preferences check out the csrActive settings manually.
 
Are you sure about csrActive? If you use the latest clover builds 0x03FF checks off all the boxes. I know there is one for unapproved Kexts.


@Gigamaxx,

Im running Clover r5018 with CSRActiveConfig=67 in my config.plist and it's working just fine :-

CSR_Active=67.png


Cheers
Jay
 
Last edited:
All sounds good :thumbup:

I guess as we head closer to GM status the finalised security measures will be in place. My only confusion is it seems that Apple goes to all this trouble to implement a new security measure and it gets defeated with a one-click workaround? o_O

Perhaps they don't want to discourage us after all. :)
 
Status
Not open for further replies.
Back
Top