Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Security for OCLP (OpenCore Legacy Patcher)

Omega Mac said:
One recurring comment by way of caution that I do not fully understand are those who profess to shy away from using banking on a OCLP Mac, how would this be more secure on older browsers on older versions of macOS, since current crop of Bank security measures usually require two factor, thus meaning the need to utilise a second device with Bank app to confirm log in, payment and whatever else, which inevitably will be a phone and most likely an iPhone in OCLP use cases.
Click to expand...
When this thread was first created, OCLP Documentation made claims that implied that an OCLP-patched Mac is just as secure as a fully supported Mac. This thread prompted changes to the OCLP documentation, so that this claim is no longer made (in fact, in this very thread, one of the primary OCLP Devs states that an OCLP-patched Mac will never be as secure as a fully-supported Mac). Read the 2nd post in this thread to learn more about initial OCLP claims.

For those who care about security, the comparison to be made is an OCLP-patched Mac running macOS version A to a fully supported Mac running macOS version A. It would be a mistake to assume that an unsupported Mac running macOS Version A with OCLP is just as secure as a fully supported Mac running macOS Version A without OCLP. It would also be a mistake to blindly assume that a Mac that natively runs Ventura (without OCLP) is less secure than the same Mac running Sequoia (later than Ventura) with OCLP. The mistake made by the uninformed will be to assume that a Mac running a later version of macOS is automatically more secure than the same Mac running an older version of macOS. The use case cannot be ignored (e.g., home office Ethernet vs. coffee shop Wi-Fi) for reasons including the following:
  • OCLP is software, software has bugs and there is no certification testing of OCLP
  • The Wi-Fi framework injected by OCLP into Macs no longer supported after Ventura is "frozen" at Ventura. Combine this with the fact that the patched legacy Wi-Fi Framework in Sonoma, Sequoia and soon Tahoe (which is an old framework extracted from Ventura that is no longer receiving any updates) is a Wi-Fi framework that is not subject to any certification testing. It would be a mistake to believe that one can implement "User Space" protections to remedy Layer-2 vulnerabilities introduced by an out-dated, uncertified Wi-Fi framework.
  • The OCLP patches are extracted from older versions of macOS and come with any vulnerabilities that were fixed in later versions of macOS. Thus, the OCLP-patched Mac running Sequoia (for example) may now have old vulnerabilities from Ventura that were fixed in Sequoia. Without certification testing, there's no way to know.
  • Many will assume that, because OCLP is open source on GitHub, that it must be secure because everyone is free to view the code. There are numerous vulnerabilities that cannot be tested by inspection. Without certification testing of an OCLP-patched Mac (with disabled SIP and broken APFS seal), there is no way to conduct a proper risk assessment.
 
Last edited:
  • Like
Reactions: olad, Omega Mac and Madhatter32
The number of unofficial direct download links to forks of Open Core Legacy Patcher has increased significantly as users eagerly await the "official" release of OCLP by the original developers. The creators of these new forks and the people sharing the links are posting them as "OCLP 3.0.0" with nothing to distinguish them from the official source and official builds.

Be extra careful about clicking links. At the time of this post, the OCLP Devs are still asking that the direct links to OCLP Nightly Builds should only point to this page.

Do not share any links to these binaries in forums; please link to this document only.
 
Last edited:
  • Like
Reactions: olad, jbn858273, basslik and 1 other person
deeveedee said:
At the time of this post, the OCLP Devs are still asking that the direct links to OCLP Nightly Builds should only point to this page.
Click to expand...
That page has a broken link.
"For developers wishing to validate mainline changes, you may use this link: GUI (Graphical Based App) https://nightly.link/dortania/OpenC...ld-app-wxpython/main/OpenCore-Patcher.pkg.zip"
gets "Error 404 – Not Found"

When opening https://nightly.link/dortania/OpenCore-Legacy-Patcher/workflows/build-app-wxpython/main
the warning is "Warning: the latest successful run is older than 90 days, and its artifacts likely expired."

Typical incompetence from the OCLP developers.
 
  • Wow
  • Sad
Reactions: olad and deeveedee
bogdanw said:
Typical incompetence from the OCLP developers.
Click to expand...
Very constructive, thank you for your comments. The nightly build link has expired and won't return until there is actually a Tahoe nightly build published by the OCLP developers. There is currently no "official" OCLP nightly build for Tahoe. Anyone who has reviewed the source knows that the OCLP developers are far from incompetent.

I just inspected the OCLP "macos-next" source. It still blocks Tahoe patching:
Code: 
_max_os = os_data.sequoia.value
 
Last edited:
  • Like
Reactions: olad
deeveedee said:
The nightly build link has expired and won't return until there is actually a Tahoe nightly build published by the OCLP developers. There is currently no "official" OCLP nightly build for Tahoe.
Click to expand...
If no official nightly builds are provided, the page should clearly state so.
deeveedee said:
I just inspected the OCLP "macos-next" source. It still blocks Tahoe patching:
Code: 
_max_os = os_data.sequoia.value
Click to expand...
False https://github.com/dortania/OpenCore-Legacy-Patcher/commit/dba48072fdc02ad07fbec07c4e92663ebbd3c94b
 
@bogdanw Take your time and inspect what you posted. Let us know when you realize your mistake.

Here's a hint
The unblock you posted is for downloading macOS installers - not for applying post install patches. With the commit you posted, OCLP can now be used to build macOS Tahoe installers.

Please do your homework more carefully.

I'm guessing that you have never reviewed the OCLP code based on your comments in this thread and your last incorrect post. Those who have reviewed the code would easily know that a commit to products_appledb.py couldn't possibly have anything to do with post-install patches. They'd also know that the Devs are very competent.
 
Last edited:
  • Like
Reactions: olad
I apologize for Jazzzny’s failed merge literally named “unblock tahoe”. Maybe someone will manage to do it wright in the next few days.
 
@bogdanw Nice try. The commit did not fail. Clone the source and you'll see.

EDIT: For those who are trying to follow this as bogdanw tries to cover his tracks, the reason that bogdanw's referenced "Unblock Tahoe" commit does not unblock OCLP patching (it only unblocks macOS Tahoe Installer download) is that there are other elements in the OCLP patcher that are not ready for patching. Even if you edit the ./opencore_legacy_patcher/sys_patch/patchsets/detect.py source yourself to unblock Tahoe patching, the patcher will fail because the required patching binaries are not yet included.

While "Unblock Tahoe" is the name of the commit here referenced by bogdanw, an examination of the actual commit tells the true story. When the rest of the patcher is ready, Tahoe patching will be unblocked in a new commit.
 
Last edited:
  • Love
Reactions: olad
@bogdanw When you're in a hole, stop digging. This is part of the reason that the Devs have asked us not to share direct links to binaries and have asked us only to share links to this page.

The patcher link that you posted further illustrates what I have already tried to explain to you. Because Tahoe patching is still blocked, an attempt to patch macOS Tahoe using OCLP from the link you provided produces the message "Unsupported Host OS"

Screenshot 2025-12-06 at 6.08.31 AM.png


You do realize that this is a public thread and that your posts are on display for everyone to read, don't you?

When a nightly build is ready for public consumption, this page will once again link to a build available for testing. Until then, let's be patient.
 
Last edited:
  • Haha
Reactions: olad
The nightly releases above are signed by Mykola Grymalyuk (S74BDJXQMD). If they don't want them public, they should stop making them.
 
The process that produces the build artifacts that you posted is automated. The builds are perfectly good and work exactly as they are intended. If you want to use the patcher at the link you posted, feel free to use it with macOS Big Sur Through Sequoia. It's not yet ready for Tahoe and is not intended to be.
 
To summarize:
1. Nightly builds from the main branch are broken for no reason. They wouldn’t offer 3.0.0, just 2.4.1 with the latest changes since 1 September.

2. Nightly builds from the macos-next branch are available, valid, but the developers are upset people are sharing the links and insist to point to the broken ones.

3. The “unblock tahoe” commit only managed to unblock downloading Tahoe, as if anyone in their right mind would download OCLP to download Tahoe.
https://mrmacintosh.com/macos-tahoe-full-installer-database-download-directly-from-apple/

Keep up the good work!
 
@bogdanw This is getting tiring. You are intentionally polluting this thread with misinformation driven by what seems to be hatred for the OCLP Devs because (as you have claimed) they are Russians producing Russian warez and they are incompetent. Mission accomplished (although I don't think it's the mission you intended).

The reason that users build macOS installers with OCLP is because OCLP pre-patches the installers for unsupported Macs. Artifacts (like those that you posted) are a snapshot in time. When completed and ready for public consumption, OCLP 3.0.0 will be able to build pre-patched macOS Tahoe installers and will be able to patch Tahoe.
 
  • Like
Reactions: olad, jbn858273 and basslik
deeveedee said:
@bogdanw This is getting tiring. You are intentionally polluting this thread with misinformation driven by what seems to be hatred for the OCLP Devs because (as you have claimed) they are Russians producing Russian warez and they are incompetent.
Click to expand...
You are misrepresenting what I’ve said.
You know very well what I've really said is true, you acknowledged it in the private conversation you started in 2023. Since then, I haven’t said anything about that issue, but you keep bring it up. It’s time to stop.
deeveedee.jpg
 
@bogdanw I apologize - it was not my intent to misrepresent your statements.

The message I sent you back in 2023 when this thread first started asked you to eliminate the personal nature of your accusations (there was no need to make this discussion about any of the Developers' nationalities as you did here when I sent the message to you). I sent you the PM after publicly asking you to retract your Russian warez claims here. By the way - "good content for Discord" is not my way of condoning your message - quite the opposite.

I brought up the old personal attack to highlight what seems to be a pattern: first a personal attack on developer nationality and now a personal attack on developer competence.

Let's just keep this thread professional without the personal attacks and derogatory comments directed toward the developers. They're human and most (maybe all?) are members of MacRumors.


EDIT: You forgot to post this part of my PM to you:
Screenshot 2025-12-07 at 5.10.46 PM.png

EDIT2: Like you, I am eagerly awaiting resumption of the nightly builds. Some of the developers and/or testers occasionally visit the Unsupported Tahoe Thread to provide updates. They're hoping to have the next "nightly" available in early 2026.
 
Last edited:
Besides being a fact and not a personal attack, “Russian” is a vital piece of information in the context of cyber security and in this case particularly.

In the best case scenario, the GitHub account vit9696, the main developer of OpenCore and many of the kexts included in OCLP, is controlled by Vitaly Cheptsov, a researcher at the Ivannikov Institute for System Programming of the Russian Academy of Sciences, Moscow, Russia, institution under US sanctions.
https://www.opensanctions.org/entities/NK-6rL5PSghBVXmNdjNgjZuF4/

Other developers involved in the project, like Andrey1970, are prominent members of the Russian warez forum that I will not publicly mention.

We’ll assume that Vitaly, Andrey and the rest are benevolent enthusiasts, hacking macOS defenses to allow more people to use macOS on PCs or on Macs that are no longer updated by Apple.

But OCPL users should be aware of this information and decide for themselves if it’s important or not.

I never used OC/OCLP and I have no intention of using it in the future.
 
@bogdanw @deeveedee:
  1. I never get involved in forum disputes or worse.
  2. Despite having a long and I hope still distinguished career in IT, I am definitely nowhere near of a programmer, coder, or whatever you would each describe yourselves to be, as either of you.
  3. Like many other enthusiasts benefitting from OCLP I have been following your debate keenly but with incomplete understanding.
The above is my preamble to allowing myself to ask the obvious stupid question: Github is a public platform expressly permitting viewing of the source code, and if preferred, running one's own build of the tools derived from it. Regardless of the nationality, mother-tongue or country of residence of any or all of the participants in the OCLP Project, how then is the tool inherently suspicious, corrupt, dodgy, untrustworthy or other diabolical spawn of the Devil? True, I am not savvy enough to make my way through the source and sign it off without taking days or weeks of time that I do not have. But others are, can, and doubtless do.

I have a Russian colleague (not living in Russia) with whom I work daily. He is no more or less trustworthy than I am in respect of my REDACTED country of origin. That last bit was attempted humour, or humor if you prefer.

EDIT: tidied up spelling and grammar
 
  • Like
Reactions: olad
@jbn858273 I have a lot of respect for vit9696 and his Acidanthera team. He and the other contributors are brilliant. His country of origin doesn't bother me in the slightest. I regularly review the Acidanthera kexts and Open Core source on GitHub and have no problem with any of it.

I have tried my best to keep my comments in this thread focused on exposing the security issues associated with the way OCLP achieves its patching magic as I have stated here. Users of OCLP should be entitled to know the compromises and trade-offs that they are making by choosing an OCLP-patched, unsupported Mac over a fully supported Mac. I think that OCLP documentation should spell out the security issues and until then, I hope this thread fills that void.

I think OCLP is amazing and have much respect for its developers. If the OCLP developers could have enabled newer versions of macOS on older, unsupported platforms without compromising security, they would have done so.

EDIT: Note that Open Core Legacy Patcher (OCLP) is not Open Core (OC). Part of OCLP's magic is based on and uses OC. I use Open Core and Acidanthera kexts on some of my trusted platforms. It is for my own personal reasons (explained in this thread) that I do not use OCLP on any of my trusted platforms. I am not advising anyone to use or not to use OCLP and assume that each will make his/her own educated decision.
 
Last edited:
  • Like
Reactions: bzgnyc2, olad, Subarctic5216 and 1 other person
@deeveedee A question if I may - as a sanity check.

I bought a TP-Link USB Bluetooth dongle a while back to see if I could switch to it in lieu of the built-in Apple Broadcom unit. No luck. Except that after updating to Sequoia 15.7.4 a couple of days ago I discovered that Bluetooth works independently of the OCLP Root Patches, and in fact not - as I thought - through the USB dongle. That got me thinking, and since I use a 5G TP-Link Deco Base Station in my home office I moved it onto my desk and connected the iMac using Ethernet. Lo and Behold I have full functionality without having applied OCLP root patches.

So, my question - since this is a clean re-installation of Sequoia, am I right in believing that the integrity of my iMac is whole? In which case I might add back my work Office 365 Account and other work-related activities that I banished several months ago.

For general information: I installed Tahoe 26.3 onto a spare SSD to test since not needing OCLP. The Ethernet port does not work, at least maybe some driver installs required. So although Tahoe still supports Intel chipsets - I updated my 2019 MacBook Pro in the certain and sure knowledge of getting one more round of supported MacOS versions - Apple are definitely winding something down.

PS: I have a combined Wi-Fi and Bluetooth dongle arriving from Amazon tomorrow, and will experiment some more with Tahoe and without OCLP.
 
jbn858273 said:
PS: I have a combined Wi-Fi and Bluetooth dongle arriving from Amazon tomorrow, and will experiment some more with Tahoe and without OCLP.
Click to expand...
iMac 2017 and Tahoe are not a happy combination, plus even the Ethernet port does not work. Sticking with Sequoia and without OCLP.
 
I'm not a technician, just a simple user. From what I understand, OCLP disables security controls to work. My question is: at this point, is it better to stay on a no longer supported Mac or accept the compromises of OCLP? Even though I make basic use of my late 2015 iMac, I use it for online banking on Monterey.

I know the answer would be to buy a new Mac and stay on a supported system, but what would be the lower risk between an unsupported system and OCLP?

Thanks to the developers for the time they've spent making older machines still valid, perhaps not suitable for critical operations like online banking, but still good enough for posting on a forum like MacRumors.

I'd especially appreciate the opinions of those who seem to have opposing views on this matter: @deeveedee and @bogdanw.

Thanks in advance in any case to anyone who has the time and inclination to answer this question of mine.
 
Last edited:
Sh3ldon said:
I'm not a technician, just a simple user. From what I understand, OCLP disables security controls to work. My question is: at this point, is it better to stay on a no longer supported Mac or accept the compromises of OCLP? Even though I make basic use of my late 2015 iMac, I use it for online banking on Monterey.

I know the answer would be to buy a new Mac and stay on a supported system, but what would be the lower risk between an unsupported system and OCLP?

Thanks to the developers for the time they've spent making older machines still valid, perhaps not suitable for critical operations like online banking, but still good enough for posting on a forum like MacRumors.

I'd especially appreciate the opinions of those who seem to have opposing views on this matter: @deeveedee and @bogdanw.

Thanks in advance in any case to anyone who has the time and inclination to answer this question of mine.
Click to expand...
That's a tuff choice, and I would probably lean towards no longer supported system if you had too. However I think there is a third option and it's linux Mint. I run it on my 2012 Mac mini and it was pretty easy to get set up. There is also plenty of help on line if you get stuck
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back