OpenCore-Patcher Developer Discussions not for general users

[gandolf243]

@albert-mueller this code for some reason is not complete, there is code missing that I saw on @Medelcartelinc's fork. @Medelcartelinc don't delete your fork yet. Am I over reacting? Or is this real? all I know is that there are still bug in this code that I thought had gotten fixed. I want to work on this, but I need to know where the code went.

[Medelcartelinc]

Hi @gandolf243 Yes, you are right. I have been heavily working on my Medelcartelinc fork to fix several critical bugs in the T1 Experimental Support. Specifically, I fixed the os.execl restart crash, cleaned up the Mode Selector UI, and just added a bypass in subprocess_wrapper.py to fix the OCLP_PHT_ERROR_INVALID_CERTIFICATES error when the app is launched via sudo on unsigned builds. I am opening a Pull Request right now to bring all my fixes into your repo!

[albert-mueller]

@albert-mueller this code for some reason is not complete, there is code missing that I saw on @Medelcartelinc's fork. @Medelcartelinc don't delete your fork yet. Am I over reacting? Or is this real? all I know is that there are still bug in this code that I thought had gotten fixed. I want to work on this, but I need to know where the code went.

Nope, it's not overreacting. Some pieces of code are completely missing, patches for T2 Macs have completely messed up and other stuff and managed to fix the messed up T2 patches. However, the code is currently highly unstable and not ready for being released. The last version that was released before this PR getting merged.
Icons are also messed up, and other stuff. I think it's time to wait for another PR before releasing anything.
@gandolf243 @Medelcartelinc

[albert-mueller]

So before releasing anything I test the application logic and also do some testing and research on Mac mini 2018 and MacBook Pro 2020 4 thunderbolt 3 ports.

[gandolf243]

@albert-mueller, if you want, I could test the App on my Mac too. You would just need a way to get it to me.

[Medelcartelinc]

Hi @albert-mueller and @gandolf243! Don't panic, the code is not lost! 😅 I intentionally cleaned up the GUI and hid the T1 Experimental Mode (like the Mode Selector and T1 patches) because I wanted this PR to focus only on your critical bugs (the os.execl crash and the PHT sudo bypass) to keep it stable for your T2 users. Also, in my latest two commits, I just restored the missing UI buttons and icons in your standard mode that I accidentally removed during the cleanup.

The T1 Experimental code is perfectly safe on my end. Test these fixes on your hardware, and once we merge this, I can easily open a separate PR with the Dual Mode Selector and the T1 Tahoe patches so we can work on them together!

[albert-mueller]

Hi @albert-mueller and @gandolf243! Don't panic, the code is not lost! 😅 I intentionally cleaned up the GUI and hid the T1 Experimental Mode (like the Mode Selector and T1 patches) because I wanted this PR to focus only on your critical bugs (the os.execl crash and the PHT sudo bypass) to keep it stable for your T2 users. Also, in my latest two commits, I just restored the missing UI buttons and icons in your standard mode that I accidentally removed during the cleanup.

The T1 Experimental code is perfectly safe on my end. Test these fixes on your hardware, and once we merge this, I can easily open a separate PR with the Dual Mode Selector and the T1 Tahoe patches so we can work on them together!

I didn’t got panicked fortunately. It happens. The world hasn’t ended because of broken source code 😀.

[gandolf243]

Good! You did leave some bugs in the code though, the save openCore is broken and I took me a moment (after I realized that it wasn't building) to find the build opencore button, this is slower, especially since I was considering auto selecting the partition for the user if the the EFI or another partition was the only one available. I wasn't panicking, I was simply noticing that the code was missing and in it's place was some extra bugs, I wanted to know where it was and fix the issues, now that I know that my fixes won't be overridden, I will start fixing the bugs.

[albert-mueller]

Good! You did leave some bugs in the code though, the save openCore is broken and I took me a moment (after I realized that it wasn't building) to find the build opencore button, this is slower, especially since I was considering auto selecting the partition for the user if the the EFI or another partition was the only one available. I wasn't panicking, I was simply noticing that the code was missing and in it's place was some extra bugs, I wanted to know where it was and fix the issues, now that I know that my fixes won't be overridden, I will start fixing the bugs.

We'll work together with @gandolf243 to fix bugs. I already fixed a couple inside Settings.

[albert-mueller]

Besides bugs, I found also exploitable vulnerabilities in gui_main_menu.py only - and most of them allow attackers to execute arbitary code or launch denial of service attacks. Except one that inside the Developer mode, an attacker could confuse the patcher into selecting Option 5, 6, ü, ю, у, й, ь, ö, œ, ß or anything to cause the application to crash out of confusion attack, which is a mix of confusion attack and denial of service again. All of them were easy to exploit - even an attacker with basic Python knowledge could exploit some of them. I fixed them in the PR. And one other vulnerability allowed an attacker to perform ClickFix attacks due to lack of error knowledge.
And in build.py, just found another set of vulnerabilities - and are critical. In one instance, when deleting a directory but it fails to do so for example because an attacker tried to delete an unauthorized directory, they could escalate into a full blown denial of service attack. And another vulnerability allows an attacker to perform ClickFix attacks.
And under Test D, there was another vulnerability: kexts are injected unconditionally:
if self.constants.build_profile == "test_d":
logging.info("Profile TEST-D: Injecting Wi-Fi, Audio & System boot-args (ipc_control_port_options=0 -amfipassbeta alcid=13).")
current_boot_args = self.config["NVRAM"]["Add"]["7C436110-AB2A-4BBB-A880-FE41995C9F82"]["boot-args"]
test_d_args = ["ipc_control_port_options=0", "-amfipassbeta", "alcid=13", "-lilubetaall"]
for arg in test_d_args:
prefix = arg.split('=')[0]
if prefix not in current_boot_args:
current_boot_args = f"{current_boot_args} {arg}".strip()
# Clean out any leftover amfi=0x80 to ensure Apple Account & entitlements are functional
cleaned = [a for a in current_boot_args.split() if a != "amfi=0x80"]
self.config["NVRAM"]["Add"]["7C436110-AB2A-4BBB-A880-FE41995C9F82"]["boot-args"] = " ".join(cleaned)

                # Force Wi-Fi kexts and block
                support.BuildSupport(self.model, self.constants, self.config).enable_kext("IOSkywalkFamily.kext", self.constants.ioskywalk_version, self.constants.ioskywalk_path)
                support.BuildSupport(self.model, self.constants, self.config).enable_kext("IO80211FamilyLegacy.kext", self.constants.io80211legacy_version, self.constants.io80211legacy_path)
                support.BuildSupport(self.model, self.constants, self.config).get_kext_by_bundle_path("IO80211FamilyLegacy.kext/Contents/PlugIns/AirPortBrcmNIC.kext")["Enabled"] = True
                support.BuildSupport(self.model, self.constants, self.config).get_item_by_kv(self.config["Kernel"]["Block"], "Identifier", "com.apple.iokit.IOSkywalkFamily")["Enabled"] = True
                support.BuildSupport(self.model, self.constants, self.config).enable_kext("AirportBrcmFixup.kext", self.constants.airportbcrmfixup_version, self.constants.airportbcrmfixup_path)
                support.BuildSupport(self.model, self.constants, self.config).enable_kext("AppleALC.kext", self.constants.applealc_version, self.constants.applealc_path)

If for some reason those kexts were to be missing, an attacker could trick the user into skipping the injection of these kexts by simply deleting the entire block of kext injection to cause denial of service attacks again.

I fixed all of these vulnerabilities.
And found this bug: upon switching to Developer Mode it happens this:

boyan2@MacBook-Pro ~ % python3 /Users/boyan2/Downloads/OpenCore-Legacy-Patcher-T2-main\ 9/OpenCore-Patcher-GUI.command 
#########################################
# OpenCore Legacy Patcher (4.0.0.17003) #
#########################################
Log file set:
  /Users/boyan2/Library/Logs/Dortania/OpenCore-Patcher_4.0.0.17003_2026-08-30_09-41-12-055128.log
~/Library/Logs/Dortania/OpenCore-Patcher_4.0.0.17003_2026-08-30_09-41-12-055128.log
Current working directory: /Users/boyan2
Analytics data was not embeded.
Setting allow_native_spoofs to True
Setting allow_oc_everywhere to True
Setting custom_board_serial_number to 
Setting custom_serial_number to 
Setting disable_connectdrivers to False
Setting disable_cs_lv to True
Setting disable_fw_throttle to False
Setting enable_wake_on_wlan to False
Setting firewire_boot to False
Setting ignore_updates to False
Setting kext_debug to True
Setting opencore_debug to True
Setting override_smbios to MacBookPro16,1
Setting secure_status to False
Setting serial_settings to Advanced
Setting set_alc_usage to True
Setting vault to False
Setting verbose_debug to True
Developer Mode is OFF, bypassing Mode Selector → Standard UI
Entry point set: MainFrame
Initializing Main Menu Frame
DEBUG: Real: 'MacBookPro16,2' | Build: 'MacBookPro16,2'
Checking if the version is valid
Privileged Helper Tool permissions are already correct, no repair needed
Checking if the version is special
Checking if the version is valid
You are already on the latest version.
If this meessage appears even if it's not up to date, you should report this issue.
For most pre-alpha versions, this behavior is normal because various versions are marked as pre-release.
Initializing Settings Frame
Turning on Developer Mode
Restarting application to apply Developer Mode changes...
Python 3.13.13 (v3.13.13:01104ce1beb, Apr  7 2026, 14:43:30) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

The app doesn't crash, it closes but then fails to open. @Medelcartelinc @gandolf243 can you try to fix?

[albert-mueller]

Good! You did leave some bugs in the code though, the save openCore is broken and I took me a moment (after I realized that it wasn't building) to find the build opencore button, this is slower, especially since I was considering auto selecting the partition for the user if the the EFI or another partition was the only one available. I wasn't panicking, I was simply noticing that the code was missing and in it's place was some extra bugs, I wanted to know where it was and fix the issues, now that I know that my fixes won't be overridden, I will start fixing the bugs.

The Save OpenCore is broken since a couple of releases, prior to this broken pull request.
@gandolf243 @Medelcartelinc

[gandolf243]

The Save OpenCore is broken since a couple of releases, prior to this broken pull request. @gandolf243 @Medelcartelinc

Will fix it.

[gandolf243]

Hey, @albert-mueller I just added a apple provided authentication and did a minor design overhaul, I fixed the save opencore button, and added one or two features. Hope you enjoy the changes.
Question, have you heard of Open Router? It is the only site I have ever seen to actually offer FREE AI APIs!!!! you get 50 requests/d and you can set on server guardrails, this can replace your Gemini site link with a custom UI and a bot that is tailored to helping with OpenCore-Patcher-T2. just, keep your API key private, inject it as a build arg.
Idea, you where talking about how glad you where that you removed the ignore app updates checkbox, however I think you should add it back with the following adjustment: say we keep the source code to each version that is released, then, say the user clicks the ignore button, the wouldapp would ignores all updates EXCEPT ones that are labeled with a critical tag, then, it downloads a old_support.json file that is attached to the release, it uses this to see if the app version is supported in this release, we can use the old source code that we have store to only provide security updates, and not feature updates. we can even use this to tell older versions when support is dropping so it can alert the user.
Just an idea, thought you might like to hear.

[albert-mueller]

Hey, @albert-mueller I just added a apple provided authentication and did a minor design overhaul, I fixed the save opencore button, and added one or two features. Hope you enjoy the changes.

Question, have you heard of Open Router? It is the only site I have ever seen to actually offer FREE AI APIs!!!! you get 50 requests/d and you can set on server guardrails, this can replace your Gemini site link with a custom UI and a bot that is tailored to helping with OpenCore-Patcher-T2. just, keep your API key private, inject it as a build arg.

Idea, you where talking about how glad you where that you removed the ignore app updates checkbox, however I think you should add it back with the following adjustment: say we keep the source code to each version that is released, then, say the user clicks the ignore button, the wouldapp would ignores all updates EXCEPT ones that are labeled with a critical tag, then, it downloads a old_support.json file that is attached to the release, it uses this to see if the app version is supported in this release, we can use the old source code that we have store to only provide security updates, and not feature updates. we can even use this to tell older versions when support is dropping so it can alert the user.

Just an idea, thought you might like to hear.

Doesn't it come at the cost of CPU and RAM? Old Macs aren't powerful enough to handle AI locally in any way. That's why I implemented a WebView window instead.
I haven't used a Mac with a Core 2 Duo but used non-Apple hardware with Core 2 Duo E7500 and can handle only Windows 8.1.

[gandolf243]

Doesn't it come at the cost of CPU and RAM? Old Macs aren't powerful enough to handle AI locally in any way. That's why I implemented a WebView window instead.
I haven't used a Mac with a Core 2 Duo but used non-Apple hardware with Core 2 Duo E7500 and can handle only Windows 8.1.

Yes, if you run it locally say on my mac, if it was on High Sierra, the oldest version of chatgpt (which i don't recommend using because it outputs nonsense) would take 7min for a paragraph or two and in the mean time my fan would see if it could convert my mac into a airplane! but this is FREE, preset-up, cloud hosted AI models, the free version randomly selects between Gemini, ChatGPT and Claude to answer your request. that is why I like that site. No on-device models, all cloud hosted, 50 request/d, we can set in-app limits to help keep it open for others or see how much it would cost for more requests.

[gandolf243]

what do you think of my update idea?

[gandolf243]

is it OK, if I start setting up documentation in the wiki page?

[gandolf243]

also, is OpenCore-Patcher T2 signed? if so, then I would want to setup notifications instead of Dialogs. (I would keep dialogs as the fall back if 1, the binary was not signed, 2, if the user didn't let OpenCore-Patcher T2 send notifications.

[albert-mueller]

also, is OpenCore-Patcher T2 signed? if so, then I would want to setup notifications instead of Dialogs. (I would keep dialogs as the fall back if 1, the binary was not signed, 2, if the user didn't let OpenCore-Patcher T2 send notifications.

The app is self signed, though.

[gandolf243]

So the app is not signed with a apple Developer Account?

[albert-mueller]

So the app is not signed with a apple Developer Account?

Yes

[gandolf243]

sad. Wish I could sponsor one, because notifications would improve it a lot.

[gandolf243]

Hey @albert-mueller, you missed it, some one got a macrumors account just to accuse us of stealing free software! (i.e, OCLP)

[gandolf243]

@albert-mueller, it was in the macOS Tahoe on unsupported Macs discussion, right here: bad post I already posted a few things for them to chew on. then the official OCLP devs came back into the scene. Right now is a great time for you to be on that thread.

[albert-mueller]

crystall1nedev
macrumors newbie
29 minutes ago
#2,069

not stealing
looks inside
"If it is anything different from what Albert has, I will need to add it."

Additionally you took the Sequoia + Tahoe WiFi patches as soon as they were available, you are building off of the existing OCLP base, and the only thing you have done differently is asked Gemini repeatedly how to fix a problem it does not understand.

I'm usually calm and collected but people like you are part of the reason Tahoe support took this long. People like you are part of the reason we had a distinction between public and internal, and people like you are part of the reason talented developers like EduCovas no longer wish to work on the project.

Think of it this way: when you spend months to years working on something you cherish deeply, whether it be for noble reasons like helping the little guy who can't afford a new Mac, or because it's something you really like doing... and then the next second, someone else is choosing to carelessly use it and act like its their own? It's not stealing, you're right, but just because it isn't stealing doesn't mean it's any less disrespectful to the people who took their time to write it.
Is this what you meant?
@gandolf243

[gandolf243]

no, it was up a bit. the post by macintoshgod.

[albert-mueller]

Gandolf243 said:
What!!! I need to look into this! If it is anything different from what Albert has, I will need to add it.
So you guys just steal everything, damn
Yeah
They were likely angry me to bring Dortania's changes to my own PatcherSupportPkg.
So to fix this, I'm migrating to Dortania's own PatcherSupportPkg, and will add if there are missing patchset, so I can benefit from their codebase without actually bringing friction to their own developers.
@gandolf243
Isn't this better than porting Dortania's changes to my PatcherSupportPkg otherwise?

[gandolf243]

well, as was hotly debated in the rest of the forum, we are allowed to do what we are doing. But it is up to you. I would read the rest of the posts up to current. they bring out not only what we are allowed to do, but they also show how dortania responses to us. It is a really good read, and you might be able to get a thing or two in about our branch.

[gandolf243]

@albert-mueller, Sorry, I unfortunately went too far over in mac rumors and got crystall1nedev to say "I genuinely have no words to say in response to you or anyone involved with the OCLP T2 fork if this is how you're going to act."

[gandolf243]

@albert-mueller, don't downgrade metallibs because of me. Nor would I touch the forums right now, I kind of made it a hostile environment for us.

[albert-mueller]

The metallibs are untouched I think? PatcherSupportPkg I don't think uses Metallibs if I'm correct?
@gandolf243

[gandolf243]

@albert-mueller, sorry, thought you said metallib. But, don't switch because of me. tahoe only works because of your custom PatcherSupportPkg, if you swich you will lose audio and wi-fi on tahoe.

[albert-mueller]

I backported the older patches into my fork that were missing otherwise.

[Medelcartelinc]

Well, I have to say this is kind of a pain in the ass 😂

After all the work we put into this — the patches, AMFI, LoginWindow, T1, Polaris, Tahoe, etc. — Dortania releases OCLP 3.0.0 and basically makes a big part of what we were doing redundant.

I’m still testing their version though. I tried it on the Mac that I had basically given up on, since I had already managed to get it working with our patches. I reverted everything, rebuilt the EFI, applied the patches and started testing from a clean setup.

There are still some issues that I’ve noticed, so it’s definitely not completely perfect yet. I’ll keep testing it and see what breaks and what actually works reliably.

That said, Touch ID is a pretty impressive achievement. It actually works, and they managed to bypass/handle that part, so credit where it’s due.

Still… after everything we went through to get this working ourselves, seeing 3.0.0 come out right after is a little painful

[Medelcartelinc]

@albert-mueller @gandolf243 Sorry, I accidentally deleted my previous message! I read your reply Albert ("Can we reintroduce these then?"), and the answer is absolutely YES. We have everything isolated in our fork and we can definitely do a clean rebase to reintroduce all those custom patches on top of the new base.

Just to reiterate what I posted before, if we switch blindly right now, we will lose our Tahoe support. Here is the breakdown of the specific modifications we currently have in our fork that need to be preserved:

Wi-Fi (Tahoe): We manually reintroduced wifip2pd, IO80211.framework, and WiFiPeerToPeer.framework to restore AWDL (Airdrop/Handoff) for the Broadcom chip on Tahoe.
Audio (Tahoe): We ported and root-patched the legacy AppleHDA.kext to restore Intel HDA audio.
T1 Support: We implemented local modifications (e.g., t1_login_experimental.py) and did a targeted downgrade of AppleSSE.kext, AppleCredentialManager.kext, and AppleKeyStore.kext from Ventura to restore Touch Bar and Camera functionality.
GPU / WhateverGreen: We adjusted the injection logic for WhateverGreen (agdpmod=pikera) and modified amd_polaris.py to fix black screen and battery drain issues on MacBookPro14,3.
I also want to add a few things to clear up the recent drama. We did not take the Wi-Fi or Audio patches from Dortania. For Wi-Fi, we sourced the frameworks from other places, and for Audio, we simply brought back legacy kexts on our own.

I spent 3 full days of my own time debugging and getting Tahoe to work perfectly on my Mac, fixing some missing things, and I also personally brought the T1 support. To be honest, I feel like they are attacking us now because we kept pushing forward while they left OpenCore development on standby for a long time. We didn't give up when things got hard. I do this entirely as a hobby, not for money. I do it mainly to keep my own old Mac alive and to help other people do the same. It might not work perfectly on every single Mac yet, but it works on many, and a lot of users have thanked us.

I honestly do not understand what that person wants from us. We are just trying to keep these machines running, which should be the whole point of this open-source community.

[Medelcartelinc]

@albert-mueller @gandolf243 Just a quick update: I am already working on this. I'm currently setting up a clean local workspace to do a proper rebase of all our custom patches (Wi-Fi, Audio, T1, GPU) on top of the official Dortania fork. I'll let you know once I have everything matched up and ready to test.

[albert-mueller]

@albert-mueller @gandolf243 Sorry, I accidentally deleted my previous message! I read your reply Albert ("Can we reintroduce these then?"), and the answer is absolutely YES. We have everything isolated in our fork and we can definitely do a clean rebase to reintroduce all those custom patches on top of the new base.

Just to reiterate what I posted before, if we switch blindly right now, we will lose our Tahoe support. Here is the breakdown of the specific modifications we currently have in our fork that need to be preserved:

Wi-Fi (Tahoe): We manually reintroduced wifip2pd, IO80211.framework, and WiFiPeerToPeer.framework to restore AWDL (Airdrop/Handoff) for the Broadcom chip on Tahoe.

Audio (Tahoe): We ported and root-patched the legacy AppleHDA.kext to restore Intel HDA audio.

T1 Support: We implemented local modifications (e.g., t1_login_experimental.py) and did a targeted downgrade of AppleSSE.kext, AppleCredentialManager.kext, and AppleKeyStore.kext from Ventura to restore Touch Bar and Camera functionality.

GPU / WhateverGreen: We adjusted the injection logic for WhateverGreen (agdpmod=pikera) and modified amd_polaris.py to fix black screen and battery drain issues on MacBookPro14,3.

I also want to add a few things to clear up the recent drama. We did not take the Wi-Fi or Audio patches from Dortania. For Wi-Fi, we sourced the frameworks from other places, and for Audio, we simply brought back legacy kexts on our own.

I spent 3 full days of my own time debugging and getting Tahoe to work perfectly on my Mac, fixing some missing things, and I also personally brought the T1 support. To be honest, I feel like they are attacking us now because we kept pushing forward while they left OpenCore development on standby for a long time. We didn't give up when things got hard. I do this entirely as a hobby, not for money. I do it mainly to keep my own old Mac alive and to help other people do the same. It might not work perfectly on every single Mac yet, but it works on many, and a lot of users have thanked us.

I honestly do not understand what that person wants from us. We are just trying to keep these machines running, which should be the whole point of this open-source community.

@Medelcartelinc I totally agree with you. This isn't the first attack against this project. Previously, this project got abused for version spoofing attacks in a fork, and a vulnerability where the Build & Install OpenCore button wasn't greyed out for Hackintosh users got abused for spreading denial of service attacks against Hackintosh users. That's why my goal is to find vulnerabilities before attackers do.

[gandolf243]

@albert-mueller can I (or you) move the contents of the docs folder to the wiki tab of this repo?

[albert-mueller]

@albert-mueller can I (or you) move the contents of the docs folder to the wiki tab of this repo?

Is it ok for you only to copy instead of move? There are also some licenses as well as far as I checked the folder.

[gandolf243]

yes. copying is what I would be doing. I will do that!

[gandolf243]

@albert-mueller, I got five pages in. we still need to update all the links and some other stuff, but it is working well. I would do more but my Mac is slowing down, I am going to restart and then see where I am from there.

[gandolf243]

@Medelcartelinc @albert-mueller hey! I am going to bed but I just want to say this: please help me boot tahoe here:

macOS Tahoe 26 on unsupported Macs discussion post by Gandolf243

[gandolf243]

@albert-mueller, I am changing how I go a this. I am instead going to create a domain called "albert-mueller.github.io/OpenCore-Patcher-T2" and host the docs there. does that sound OK?

[gandolf243]

@Medelcartelinc, can you help me get the docs folder up on the web like Dortania does? I think I almost have it. I just uploaded the workflow but I commented it all out so that it wouldn't run.

[Medelcartelinc]

@gandolf243 Happy to help!

I checked the build-site.yml you uploaded. You were super close! There were just two small details keeping it from running properly:

1. VitePress vs VuePress output path: The docs folder uses VitePress, so the build output lands in docs/.vitepress/dist/ (not .vuepress).
2. Owner Typo: There was a small typo in the condition check (albert-meuller instead of albert-mueller).

Here is the clean, un-commented workflow you can drop into .github/workflows/build-site.yml:

name: CI - Build Site

on:
  push:
    branches:
      - main
    paths:
      - 'docs/**'
      - '.github/workflows/build-site.yml'
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    name: Build Site
    runs-on: ubuntu-latest
    if: github.repository_owner == 'albert-mueller'
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: "recursive"

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "yarn"
          cache-dependency-path: docs/yarn.lock

      - name: Install Dependencies
        run: yarn install --frozen-lockfile
        working-directory: docs

      - name: Build with VitePress
        run: yarn run build
        working-directory: docs

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: docs/.vitepress/dist/

  deploy:
    name: Deploy to GitHub Pages
    if: github.repository_owner == 'albert-mueller' && github.event_name == 'push' && github.ref == 'refs/heads/main'
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

[gandolf243]

@Medelcartelinc, there is a issue, dortania has a environment that they are using. We don't know what that has:

  environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

[Medelcartelinc]

@gandolf243 Don't worry at all, that's not a secret or custom environment!
In GitHub, github-pages is the official, built-in environment provided by GitHub itself for all repositories. There are no hidden configs or special secrets in it.
Here is how it works
. All that Albert needs to do in the repository settings is:
Go to Settings ➔ Pages ➔ under Build and deployment / Source, select "GitHub Actions" (instead of "Deploy from a branch").
Once that option is selected, GitHub automatically provisions the github-pages environment for the repo.
. The step actions/deploy-pages@v4 handles everything natively, and ${{ steps.deployment.outputs.page_url }} simply outputs the final site URL (e.g. https://albert-mueller.github.io/OpenCore-Legacy-Patcher-T2/).
You can keep that environment block as-is once Albert toggles that single setting in the repo, the workflow will run and deploy smoothly!

[gandolf243]

@Medelcartelinc, great!

[albert-mueller]

@Medelcartelinc Breaking news! Now the prebuilt Priveleged Helper Tool binary is no longer there to mitigate a vulnerability where an attacker could abuse it for delivering malware by abusing my own signature. So from 190009 onwards, if you want the patcher to include a Priveleged Helper Tool, now you'll have to build the binary.

[albert-mueller]

Also, 190009 fixes a couple of vulnerabilities that someone disclosed in MacRumors: https://forums.macrumors.com/threads/security-for-oclp-opencore-legacy-patcher.2406586/page-13
It's definately not very ethical to disclose vulnerabilities in a public forum instead of GitHub Security Advisories, but it is what it is.

[gandolf243]

@albert-mueller, the docs should be on the web after you do this:
Go to Settings ➔ Pages ➔ under Build and deployment / Source, select "GitHub Actions" (instead of "Deploy from a branch"). You need to do it in the OCLPT2 repo, not the albert-mueller.github.io one.

[gandolf243]

@albert-mueller, can you please do this?

[albert-mueller]

I just did it. Now the site is live: https://albert-mueller.github.io/OpenCore-Legacy-Patcher-T2/START.html
However, certain changes need to be done in regards of the page, as we have redesigned the app and works differently than Dortania's versions.

[albert-mueller]

@gandolf243

[gandolf243]

@albert-mueller, great!!!! Yes, do need to do a lot of maintenance. the good part is that all we have to do is edit markdown docs and click commit.

[gandolf243]

@albert-mueller, I just make some fixes to the docs, we still have a lot left. I did set off a ton of license errors when I gave you the copyright instead of leaving it with Dortania.

[albert-mueller]

@gandolf243 I archived only temporarily the repo and unarchived it immediately to test an End of life warning if the repo ever gets archived to ensure if the repo gets archived or deleted, the users will immediately get notified:

[matteoiacca]

Hey @albert-mueller, @gandolf243
Just wanted to give you a quick heads-up regarding my GitHub account situation:
Unfortunately, I haven't been able to recover my original GitHub profile. I've tried reaching out to GitHub support multiple times, but I keep getting looped into automated AI responses with zero human support.
At this point, it looks like I'll be continuing and starting fresh from this account (@matteoiacca) moving forward. It’s definitely frustrating because I had built up a lot of my reputation, history, and projects on that account. Fortunately, I have local and server backups of most of my code, though I still need to dig through some older drives to see if there's anything else I can salvage. I still hope I can get it back someday, but I don't want it to stall things here.
I wanted to clarify this so there’s no confusion and you know it's still me. I'm really looking forward to continuing our collaboration here on OCLP-T2 and Tahoe. Right now I've also been spending some time modding and tinkering with various personal devices on the side, but I'm fully here and ready to keep pushing things forward with you guys.

[gandolf243]

@matteoiacca, I am sorry that that is the case. you could try and see if you can get anything from https://archive.org, maybe run like git clone archive.org/date/github.com/Medelcartelinc/repo,git (I don't know if that would work, but it is worth a try.)

@albert-mueller, don't forget to add @matteoiacca as a contributor to this and all the other repos.

[gandolf243]

@matteoiacca, this might be the case, but are you paying for github? because it looks like if you are, you can get advanced support.

[matteoiacca]

@gandolf243 It was just a standard free account, not paid, which is why support is completely automated with no way to reach a real person.
No worries though, I have all the code and patches backed up locally anyway, so nothing was lost.

[gandolf243]

@matteoiacca, I looked into it really quick, and here is what I got GitHub Support Issue Duck AI Chat the link expires in two days. I don't know if you have tried everything mentioned in it or not but it might be worth a shot.

[albert-mueller]

@gandolf243 @matteoiacca In that case, it might be better to continue with the new account, @matteoiacca . It doesn't worth the hassle to restore the old one if you have all repos backed up elsewhere.

[matteoiacca]

@gandolf243 Thanks for looking into that and sharing the link! Following the advice in that chat, I went ahead and submitted a ticket for manual review (#3487883) through this account just in case.
@albert-mueller Fully agree. I'm not going to wait around or stress over it—I'm completely moving forward with this account (@matteoiacca) so our work on OCLP-T2 and Tahoe stays on track. If GitHub eventually unblocks the old one down the road, great, but either way no code was lost and we can keep pushing forward here.

[gandolf243]

@albert-mueller, I can't create a Announcement. Can you update the lock to include collaborators or find a way to promote me and any other person that you think should be promoted to maintainer?

[gandolf243]

GUYS!!!! @Medelcartelinc account is unbanned!!! He is back!!

[albert-mueller]

Yay!

[Medelcartelinc]

Hey @gandolf243, @albert-mueller,
Thanks a lot guys! The ticket review finally went through and the original account is fully restored and operational.

[gandolf243]

@Medelcartelinc, you are welcome! Glad to have you back!

[albert-mueller]

@Medelcartelinc Hi @Medelcartelinc ! I pushed PR to your OpenCore Legacy Patcher T2 repo for the following reasons:

• the Metallibs API has been changed and the what used to be the old endpoint is now my patcher’s website
• the repository with the instructions for T2 Macs is dead, now it’s a website, the old repo is dead
• a bug where the boot.efi was still OpenCore 1.0.4 while the rest was 1.0.8 and 2.0.7 was fixed
• for non-T2 Macs, OpenCore 2.0.7 caused issues because the way T2 Macs work differ from non-T2 Macs, to mitigate certain issues, non-T2 Macs use OpenCote 1.0.8 and the 2.0.7 package is only for T2 Macs
• multiple vulnerabilities have been fixed
• overall the versions between 4.0.0.190007 and 190009.x were extremely buggy and were causing severe issues on non-T2 Macs
• new functions to this patcher are added, including now that you can erase a partition and create a macOS installer without wiping the disk

[Medelcartelinc]

@albert-mueller Thanks a lot for the heads up and the PR! I will review and merge it into my repo right away.
I also just opened a PR on your repo updating T2TahoeFixup to v1.0.6: it corrects the hardware model whitelist (restores your MacBookPro16,2 to native so the kext stays dormant, while adding MacBookPro16,1 and 16,4 to dropped models so they get Stage 2 fixup). All verified and aligned with the 2.0.7 payloads.

[albert-mueller]

Medelcartelinc#27
@Medelcartelinc Pushed this PR request to main

[albert-mueller]

Hi, @Medelcartelinc! A bug in the license check causes the removal of the documentation the License Guard to misidentify this as a license violation. And every time I pushed a PR it got closed immediately due to this bug. To fix this, you may need to update your fork on your end when possible.

[gandolf243]

@albert-mueller, which one of these images do you want to be the background of the supported Models image on the website?

don't worry if this looks bad, I just ran out of free Claude prompts for fixing up the shader.