macOS Tahoe 26 on Unsupported Macs Discussion

[Neon Ball]

I use FileVault on my Mac and it works fine. Why does it need a fix in v2.4.1?

Sequoia 15.7.2+ seem to have issues where for some users it no longer accepts their password, the FV2 fix is a test branch for a "quick and dirty" fix by Dhinak to see if it works. Theory is that Apple backported some FileVault stuff from Tahoe to Sequoia, this used to happen a lot more with Tahoe.

 

[amaze1499]

MBP11,1: clean install of 26.2 from USB installer, to external SSD, using OCLP 3.0.0 pre-built nightly for EFI.

No post-install patches, just manually putting AppleIntelHD5000Graphics.kext from Sequoia into /L/E (seems to speed graphics a bit).
As observed earlier: powering off leads to a KP, need to force off with power button (as this also happens during installation, a few forced power offs needed between install phases).

Usable as it is, with Ethernet cable. Responsive enough to write this post.

building this using terminal is still failing on my machine: OCLP 3.0.0 pre-built nightly

 

[bombardier10]

MBP11,1: clean install of 26.2 from USB installer, to external SSD, using OCLP 3.0.0 pre-built nightly for EFI.

No post-install patches, just manually putting AppleIntelHD5000Graphics.kext from Sequoia into /L/E (seems to speed graphics a bit).
As observed earlier: powering off leads to a KP, need to force off with power button (as this also happens during installation, a few forced power offs needed between install phases).

Usable as it is, with Ethernet cable. Responsive enough to write this post.

OCLP3.0 nightly support ONLY modern wireless and modern audio patches. No possible simple install graphic kext to /L/E due to connections with other kexts.

 

[bombardier10]

Ok, I'd like to step in yet again to say a few things.

To clear the air, the forks that I have seen (considering that I get emails every time they are made) don't do anything malicious - in the sense that they're trying to hinder your privacy or security. They seem to just be forking my repositories with the patches on them, building them, and publishing them.

That being said, I am in no way endorsing those forks. There are a few things that every fork has failed to properly mention about their packages:
- They seem to be building them privileged helper tool in debug mode, so they can build the app without signing. This means that those forks include a helper tool that will not check the calling process's signature before executing code. In other words, you now have sudo without a password.
- These forks require disabling AMFI as they cannot sign binaries with the Dortania key used in AMFIPass. This poses significant security risks as you can simply ad-hoc sign any binary and run it with any entitlement. This is why AMFIPass exists - that attack vector is eradicated.
- Disabling AppleVTD will break some hardware drivers, and any software that uses it.

Now, we get into the morality of these forks. Some of them are making it quite clear that they are simply forks, while others are actively trying to take credit for the work that the developers have been putting in for months. This video is a perfect example of that disrespectful, disingenuous, and misleading narrative that deprives the developers of their due.

Just be patient. If you can't wait for a pull request to be merged, then why are you here?

Apple implements various security measures mainly to make it difficult for you to use older versions of Mac.
They have little to do with security.
There is nothing wrong with looking for alternative solutions, and the current version of OCLP is safe and proven.
Of course, you can wait for the full official version, but we are not sure if it will ever be released.

 

[Neon Ball]

Apple implements various security measures mainly to make it difficult for you to use older versions of Mac.
They have little to do with security.
There is nothing wrong with looking for alternative solutions, and the current version of OCLP is safe and proven.
Of course, you can wait for the full official version, but we are not sure if it will ever be released.

You're literally talking to one of the OCLP team members, I suggest digesting what they're saying in that post.

The official release versions of OCLP use signatures to ensure that the Privileged Helper Tool only runs the proper OCLP binary as root. However the forks do not because they're forked from debug/nightly builds, this means the debug version of the tool could be used for privilege escalation without password by any malicious application whatsoever. Any application could tap to the tool and gain root privileges without asking you, because you already gave that tool full access during the installation.

The problem isn't the forks themselves particularly since OCLP nightlies work the same way, it's that don't make it clear you're taking a bigger risk by running debug versions. Same for AMFI.

 

[bombardier10]

You're literally talking to one of the OCLP team members, I suggest digesting what they're saying in that post.

The official release versions of OCLP use signatures to ensure that the Privileged Helper Tool only runs the proper OCLP binary as root. However the forks do not because they're forked from debug/nightly builds, this means the debug version of the tool could be used for privilege escalation without password by any malicious application whatsoever. Any application could tap to the tool and gain root privileges without asking you, because you already gave that tool full access during the installation.

The problem isn't the forks themselves particularly since OCLP nightlies work the same way, it's that don't make it clear you're taking a bigger risk by running debug versions. Same for AMFI.

What I mean is that we are talking about OCLP software, the official versions of which sometimes require SIP or other security features to be disabled. What's more, it is not supported or recommended by Apple...

So if we are to be consistent, we either don't use OCLP at all or we decide that these security features are not important. Do you really think that someone will create malicious applications to use some niche versions of OCLP? I don't use applications that have the ability to hack OCLP. We can write a lot about things that are almost impossible, but what's the point?

 

[deeveedee]

@bombardier10 You sound like someone knowledgeable about computer security, so you'll certainly understand that explaining the security risks as has been done here allows each of us to make our own informed choices. Each of us has our own risk tolerance and our own use cases. Knowing the details of the risks allows each of us to adjust accordingly.

Glad that you have made your choice and that you're willing to allow others to make their choice.

 

[hackintosh_user]

I use FileVault on my Mac and it works fine. Why does it need a fix in v2.4.1?

not sure, Maybe it's a Fix or Maybe implementation of the APFS_aligned EFI Driver (From what I see that is...). But Nothing that points at a Tahoe Branch