OpenCore-Patcher Developer Discussions not for general users
@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.
An dieser Diskussion auf GitHub teilnehmen100 Kommentare
Kommentare
@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 · · bearbeitet
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 · · bearbeitet
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 ·
I didn’t got panicked fortunately. It happens. The world hasn’t ended because of broken source code 😀.
@gandolf243 · · bearbeitet
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 ·
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)
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:
The app doesn't crash, it closes but then fails to open. @Medelcartelinc @gandolf243 can you try to fix?
@albert-mueller ·
The Save OpenCore is broken since a couple of releases, prior to this broken pull request.
@gandolf243 @Medelcartelinc
@gandolf243 ·
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
criticaltag, then, it downloads aold_support.jsonfile 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 ·
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 ·
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 · · bearbeitet
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 ·
The app is self signed, though.
@gandolf243 ·
So the app is not signed with a apple Developer Account?
@albert-mueller ·
Yes
@gandolf243 ·
sad. Wish I could sponsor one, because notifications would improve it a lot.
@albert-mueller ·
@Medelcartelinc I merged the PR, however, T2 and non-T series Macs need another PR. I merged the previous PR, as T1 is almost ready, remains to be tested on real T1 Mac (I have only 2 T2 Macs).
@albert-mueller · · bearbeitet
Now the code is fully complete and did a lot of testing in the previous days. And even today I deployed OpenCore to my 2020 4 thunderbolt 3 ports MacBook Pro and remoted is no longer crashing. However, issues with unsupported T2 Macs are still there.
@gandolf243 ·
hey, @Medelcartelinc I don't have time right now to work on this issue, but I got this when I was trying to turn off experimental mode when running from source, it happened after the app restart:
OpenCore Legacy Patcher encountered the following internal error:
OSError: [Errno 5] Input/output error
<FrameSummary file ~/Documents/GitHub/OpenCore-Legacy-Patcher-T2/OpenCore-Patcher-GUI.command, line 30 in >
@Medelcartelinc ·
@gandolf243 I've just pushed a fix for this bug. The issue occurred because when the .command script relaunched OCLP in the background and the main script exited, the terminal closed its standard I/O channels. When the new background process attempted to output to the now-closed terminal window, it threw the Errno 5 I/O error. I updated the restart logic to explicitly redirect I/O to DEVNULL when relaunching from source, which safely detaches the new process and prevents the crash. You can pull the latest changes.
@albert-mueller ·
@Medelcartelinc @gandolf243 I just tested signing the Priveleged Helper Tool with self signed certificate instead of using the extremely insecure make debug version. First, it's more secure, Dortania has never documented this way, but it actually works and even tested the scenario where the patcher is downloaded from the internet, and the Priveleged Helper Tool continues to function with the self signed certificate. So it's way better than what I used to do - to use the make debug version instead. And decreases the risk of throwing some weird errors. So I'm planning to ship from now onwards with a self signed certificate instead of none. It's a lot more secure, and doesn't require paying the Apple Tax.
@gandolf243 ·
Good! Now the only issue is that when running from source, you can't test as much because the privileged Helper is locked to the dev ID, which the source code can't reproduce.
@albert-mueller ·
Then it falls back to osascript.
@gandolf243 ·
Right, that makes sense. I should have thought of that.
@Medelcartelinc ·
Hey everyone,
just wanted to leave a quick note to apologize if I'm not around as often as I'd like. I work full-time in an office and I'm rarely home during the day, so my free time to dedicate to this project is unfortunately quite limited.
Whenever I do get some free time, I always try my best to jump in and solve bugs as cleanly and quickly as possible. I hope that's alright with you guys.
Also, huge thanks to @albert-mueller and @gandolf243 for all the great work you're doing and for keeping everything moving forward. Really happy to help and contribute whenever I can!
@albert-mueller · · bearbeitet
No problem. It's a project that we all do in the free time.
@gandolf243 ·
hey, sorry that commit like "Merge branch 'main' of https://github.com/albert-mueller/OpenCore-Legacy-Patcher-T2" happen. That is when I have a commit locally and someone has one that I don't have on my mac and I have to make a commit like that before I can upload my changes, so I have to upload that too.
@Medelcartelinc ·
No worries at all man, definitely no need to apologize! That's totally normal Git behavior when the remote branch has new commits.
If you ever want to keep the commit history clean and avoid those auto-merge commits in the future, you can just run:
git pull --rebase(or
git config pull.rebase trueto make it automatic).Either way, don't sweat it at all, it's completely fine!
@gandolf243 ·
can you tell me why the conditions I put on some of the stuff in the advanced menus aren't triggering? I added a
True_Developer_Modecondition toDeveloper Root PatchingandTrigger Validation. why can I click on them when I only have Experimental Mode on? Is this a issue with how I am coding or an issue with the program?@Medelcartelinc ·
@gandolf243 It is actually an issue with the GUI loop in the program, not your dictionary code.
In both
gui_settings.pyandgui_macos_configeration.py, the loop that renders the settings widgets only calls.Enable(setting_info["condition"])forcheckboxitems.When
setting_info["type"] == "button", it creates thewx.Buttonand bindswx.EVT_BUTTON, but never callsbutton.Enable(setting_info["condition"]). The only thing the code does whenconditionisFalseis change the description label text foreground colour to gray(128, 128, 128)below it, leaving the button widget itself active and clickable.To fix it, under
elif setting_info["type"] == "button":in both files, add:The same applies to
choiceandspinctrlwidgets if they ever need conditions as well.@gandolf243 ·
@Medelcartelinc, thanks! I added the button condition, I just need to build OCLP and find out if it worked! (or OCLPT2)
@gandolf243 ·
It didn't work. I built the app, the build process crashed during the signing and when I opened the app, non of the buttons that I had disabled where disabled. why?
@Medelcartelinc ·
@gandolf243 There are two distinct reasons why they weren't disabled:
You missed
gui_settings.py: in commit d66b07a, you addedbutton.Enable(setting_info["condition"])togui_macos_configeration.pyandgui_oc_settings.py, but you didn't add it togui_settings.py. The "Trigger Exception" / validation button in the main App settings lives ingui_settings.py(around line 181), so without updating that file, that button will still never be disabled.How
True_Developer_Modeis evaluated: inapplication_entry.py(line 150), OCLP checks:If you run directly from Python source, or if your build script crashed during the packaging/signing step leaving the app unfrozen (
getattr(sys, "frozen", False)is False),True_Developer_Modeautomatically flips toTrueon launch, which keeps all those buttons enabled!@gandolf243 ·
hey, thanks for that catch, that does explain it. I just fixed it!
@gandolf243 ·
@Medelcartelinc, @albert-mueller I have started on the documentation for this fork of OCLP, as it is changing so much that it needs it's own docs. do any of you want to help me write it? I have started, but there is still a lot left.
@gandolf243 ·
hey @albert-mueller, your label for the Check for Updates button is too long. Also, maybe put it in setting? after all, Apple put there check for Updates button in Settings.
@albert-mueller ·
It was easier for me to hook inside the gui_main_menu, as all other functions were there. If you can, you can move it to Settings.
@gandolf243 ·
I just moved it to settings. It's kind of funny, I was just thinking about a check for updates button when I saw that you had already implemented it.
@Medelcartelinc · · bearbeitet
Sorry guys, I’m kinda fucked these days, quitting my job probably will be active again these days. Not the best period.
Again sorry.
@gandolf243 @albert-mueller
@gandolf243 ·
hey, @albert-mueller I just added README to the about page, the cool thing is that when the app is built, the README is embeded into the binary, so it doesn't need to be added to the app's resources.
@gandolf243 ·
@albert-mueller, the png can't get though if you restrict everything to
*.icnsand the Assets.car should be in there, because that is what all of Apple's apps have@albert-mueller ·
Deleting extra binaries...
Generating DMG...
DMG generation complete
Downloading required resources...
--- Signiere Helper Tool ---
--- Sign Helper Tool ---
com.dortania.opencore-legacy-patcher.privileged-helper signieren...
Signing com.dortania.opencore-legacy-patcher.privileged-helper...
WARNING:ci_tooling.build_modules.sign_notarize:Notarization credentials not completely provided. Skipping notarization.
Erfolgreich sicher gemacht und verifiziert com.dortania.opencore-legacy-patcher.privileged-helper
Successfully secured and verified com.dortania.opencore-legacy-patcher.privileged-helper
--- Baue App ---
--- Building the app ---
Analyseschlüssel oder Endpunkt nicht angegeben, Einbettung wird übersprungen
Analytics key or endpoint not provided, skipping embedding
Generating OpenCore-Patcher-T2.app
Patching LC_VERSION_MIN_MACOSX
Patching LC_BUILD_VERSION
Warning: this checkout has no .git directory (likely downloaded as a ZIP/tarball instead of via 'git clone') - Commit Information will show N/A. Use 'git clone' (or 'git pu[...]
Warning: this checkout has no .git directory (likely downloaded as a ZIP/tarball instead of via 'git clone') - Commit Information will show N/A. Use 'git clone' (or 'git pu[...]
Warning: this checkout has no .git directory (likely downloaded as a ZIP/tarball instead of via 'git clone') - Commit Information will show N/A. Use 'git clone' (or 'git pu[...]
Warning: 'git config --get remote.origin.url' failed: Command '['git', 'config', '--get', 'remote.origin.url']' returned non-zero exit status 1.
Warning: could not determine a Commit URL (no --git-commit-url passed and no local git metadata found) - Settings will show N/A for it
Embedding git data
Embedding resources
[!] Das Aufbauen des Apps hat abgebrochen aufgrund eines Fehlers: 'PosixPath' object is not iterable
[!] Building the app stopped because of some error: 'PosixPath' object is not iterable
That was the error I was trying to fix.
@gandolf243 ·
hang on, I am trying to reproduce that error.
@gandolf243 ·
I got it too:
Maybe we do
@albert-mueller ·
Managed to fix it:
Now will release a new update to fix this issue.
@gandolf243 ·
Good Job!!!
@gandolf243 ·
the only issue I can see with the About frame is that it doesn't support dark mode.
@gandolf243 ·
fixed.
@Medelcartelinc ·
Hey guys, just a quick heads-up I noticed I’m not listed in the README credits. Since I developed the T1 support and the related patches for the 2017 MacBook Pros, I was wondering if it was maybe just overlooked. No big deal, I just wanted to mention it in case you forgot to add me.
@gandolf243 ·
will see what I can do.
@gandolf243 · · bearbeitet
how is this?
@Medelcartelinc ·
o:
Thanks, I appreciate it. I just wanted to clarify one thing though: the T1 support work I contributed wasn’t limited to what is currently mentioned in the README. I worked on the T1 support for the 2017 MacBook Pro models and developed several of the related patches and fixes as part of getting my MBP14,3 working properly on Tahoe. There was quite a bit more work involved than what is currently listed there.
I’m not trying to take credit away from anyone else, but I would just like the README to reflect the contributions accurately, especially since I spent a lot of time working specifically on the T1 side. Maybe we could take another look at the credits and make sure the full contribution is represented.
@gandolf243 ·
@Medelcartelinc, what would you prefer it reflected?
@albert-mueller · · bearbeitet
How about this?
@Medelcartelinc
@Medelcartelinc ·
Looks great to me, Albert! Thank you so much, really appreciate it. Let's get this in for now and keep pushing on Tahoe! 👍
@gandolf243 · · bearbeitet
hey, everybody (@albert-mueller, @Medelcartelinc and everybody else) this is important: I updated the build logic to support TUI, however, that requires a external module call
rich(python3 -m pip install rich) so in order to build the app from source, you HAVE to haverichinstalled. it is worth it, I don't want to do anything else and just watch it build! but, that does mean that when you are modifying the build logic, you have to userich.printinstead ofprint. but, this means that you have formatting options, e.grich.print("[red]We hit a critical error in the build process[/red]")hope you enjoy.
@gandolf243 · · bearbeitet
hey, @albert-mueller, @Medelcartelinc when you are ready for non metal work arounds/patches use my fork, which I made for that purpose. but, my Mac is still not on Tahoe. non-metal-frameworks
@gandolf243 ·
look at this:
NEW OPENCORE-PATCHER RELEASE
@albert-mueller · · bearbeitet
However, it does not add Tahoe support that one. It is mostly a bug fix update released by Dortania.
@gandolf243 · · bearbeitet
Yes, but It shows that Dortania still exists.
Just know, they could have gotten over the T2 block, and have Tahoe just about wrapped up for all we know. And if they don't, they do have the bigger and more experienced development team.
@albert-mueller ·
2.5.0 is a bug fix release to address miscellaneous issues on patched installations of macOS.
Improve stability of various macOS components utilizing WebKit on pre-AVX Macs
Resolve binary crashes caused by incorrect versioning in patched dynamic libraries
Full Changelog
2.5.0 Changelog (click to expand)
Disable repatching a dirty root volume
Prevents issues if existing patches are partially overwritten
Thanks @crystall1nedev!
Add slimmed down patchset for Modern Wireless for macOS Sequoia
Move JavaScriptCore patch for pre-AVX Macs to RestrictEvents
Additionally fixes machines without WiFi cards on Sonoma+ as the patch was not applied before
Resolve crashing caused by incorrect reported version in CoreImage patch
Increment binaries:
OpenCorePkg 1.0.4 - release
Lilu 1.7.1 - release
RestrictEvents 1.1.7 - (rolling - b70aaa4)
PatcherSupportPkg 1.9.7 - release
@gandolf243 ·
@Medelcartelinc, can you look over my non-metal frameworks repo and tell me what you think? to me, it is very fragile. (and possibly already broken!) If you want edit access, just let me know!
@gandolf243 ·
Hey @albert-mueller, I changed the update logic to use the gui_download. py file. here is a image of how it looks.
@gandolf243 · · bearbeitet
look at how the commits on dortania have just dropped:
I hope for their sake that there is a lot of background work that just isn't in public repos.
@gandolf243 ·
I just looked at Dortania's OpenCore Patcher commits and jazzzzy is the major one contributing code. the other one is crystall1nedev.
So we are actually stronger then Dortania right now.
too bad they lost their top contributors/founders to Apple.
@Medelcartelinc ·
Hey @gandolf243!
I took a look through your
non-metal-frameworksrepo!You're right that it's delicate right now because it's based on the legacy Moraea QuartzCore/SkyLight shims, which are very fragile across newer macOS versions especially going into Tahoe.
On our side, we've got the
MetallibSupportPkgfork updated with the full macOS 26 Tahoe (Darwin 25) manifest and shader pipeline (Medelcartelinc/MetallibSupportPkg).I'd love edit access so we can coordinate on the non-Metal / Metal 3802 shims and align the framework patches with our metallib pipeline for Tahoe. Send the invite over and let's get it solid together! 👍
@gandolf243 ·
I just invited you, I created the Developer discussion in 1.
@albert-mueller ·
There's a small bug where the last step says 5 out of 8 and then finishes:
Last login: Tue Sep 8 21:18:45 on ttys000
Boyans-Mac:~ boyan$ git clone https://github.com/albert-mueller/OpenCore-Legacy-Patcher-T2
Cloning into 'OpenCore-Legacy-Patcher-T2'...
remote: Enumerating objects: 12253, done.
remote: Counting objects: 100% (1544/1544), done.
remote: Compressing objects: 100% (225/225), done.
remote: Total 12253 (delta 1446), reused 1323 (delta 1319), pack-reused 10709 (from 3)
Receiving objects: 100% (12253/12253), 153.30 MiB | 10.83 MiB/s, done.
Resolving deltas: 100% (8215/8215), done.
Boyans-Mac:~ boyan$ python3 /Users/boyan/OpenCore-Legacy-Patcher-T2/Build-Project.command
Automatically selected signing identity: OCLP Self Signed
Deleting extra binaries...
Generating DMG...
DMG generation complete
Downloading required resources...
Downloading Universal-Binaries.dmg... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Signing com.dortania.opencore-legacy-patcher.privileged-helper...
Notarization credentials not completely provided. Skipping notarization.
Successfully secured and verified
com.dortania.opencore-legacy-patcher.privileged-helper
Analytics key or endpoint not provided, skipping embedding
Signing OpenCore-Patcher-T2.app...
Notarization credentials not completely provided. Skipping notarization.
Successfully secured and verified OpenCore-Patcher-T2.app
Generating OpenCore-Patcher-Uninstaller.pkg
Generating OpenCore-Patcher-T2.pkg
Generating AutoPkg-Assets-T2.pkg
Signing identity not provided. Skipping signing pipeline.
Signing identity not provided. Skipping signing pipeline.
Signing identity not provided. Skipping signing pipeline.
⠸ [5/8] Building packages
Build script completed in 245.88 seconds.
Boyans-Mac:~ boyan$
@Medelcartelinc ·
@albert-mueller The issue happens because when no
--installer-signing-identityis passed (standard for local development where only an Application identity likeOCLP Self Signedis present),sign_notarize.SignAndNotarize(...).sign_and_notarize()returns almost instantly for each package in steps 6, 7, and 8.Because the worker thread completes in sub-milliseconds and sets
done = True, therich.live.Livespinner loop (time.sleep(0.1)) terminates before catching the intermediate updates, leaving the UI visually frozen on⠸ [5/8] Building packages.The fix in
Build-Project.command:status = "[8/8] Complete"after the package loop finishes.spinner.update(text=status)immediately after thewhile not done:loop so the final completed step is guaranteed to render beforeLivecloses:@gandolf243 ·
hey, just FYI, for some reason, the URLs in the About frame can't be clicked.
@gandolf243 · · bearbeitet
Sorry I wasn't as active on this today as I would hope. My life is getting busier as things spin out of summer. I will still try to work on this when ever possible, I just wanted to make sure that you knew that I can't keep up with everything now that things are getting busier, I will try to, though.
Today it wasn't me being busier, it was me watching the Apple Event. It was cool seeing the iPhone Duo, the iPhone 18 Pro/Pro Max, AirPods 5 and the new Apple Watch unveiled. It's one of those times where you wish you had a unlimited amount of money.
If there is somthing that you want me to work on, please just let me know and I will try to work on it when I have time.
@albert-mueller
@gandolf243 ·
@albert-mueller, I think you should update the copyright and license info to your name.
@albert-mueller · · bearbeitet
https://claude.ai/share/134db3d7-c600-4d23-a9f6-9c92019f0f97
@gandolf243
@gandolf243 ·
Got it. I was more thinking adding your name, not
Dortania→ Albert Müeller everywhere. maybe just replace the one on the main menu.@gandolf243 · · bearbeitet
@albert-mueller, you have to release the AMFI fix. this user needs it. #321.
could you allow me or others to create per-releases at least, so that we can fix issue like these in the future?
@albert-mueller ·
Sorry, I'm busy today and had 2-3 appointments, do you know where to enable this option so you can release new releases, @gandolf243 as well as @Medelcartelinc ? I thought it doesn't require additional settings to be able to release new releases, nor I knew this is possible.
@gandolf243 ·
@albert-mueller, there is nothing you need to do! when you invite someone as a collaborator they automatically have the permission to make releases. I just wanted to make sure that it was OK for me and others to put out releases, or if you wanted that to be just you.
@Medelcartelinc ·
Hi @albert-mueller, no worries at all!
Just to clarify what @gandolf243 mentioned: he is right that anyone with
Writeaccess (Collaborators) can draft and publish new releases directly via the GitHub Releases page.However, I (
Medelcartelinc) am currently not a collaborator on your repository! I've just been submitting Pull Requests from my own fork (Medelcartelinc/OpenCore-Legacy-Patcher-T2).If you'd like me to be able to help manage releases, merge PRs, or push hotfixes directly without you having to review and merge them manually every time, you would need to invite me. You can do this by going to
Settings->Collaborators->Add peopleand typing inMedelcartelinc.If you prefer to keep it so that only you manage the main repository and draft the releases, that is completely fine too! I am more than happy to just keep submitting PRs. Let me know what you prefer!
(Also, regarding issue #321, once someone with Write access drafts a new release, we can push out a
1.5.0-beta2pre-release so users can immediately test the new AMFI and MacBookPro16,3 patches!)@albert-mueller ·
I did actually added you a couple of weeks ago I think. When I go to Settings > Collaborators, you're there.
@albert-mueller ·
@Medelcartelinc
@gandolf243 ·
@albert-mueller, I can make a release?
@albert-mueller ·
Yes, absolutely.
@gandolf243 ·
@albert-mueller, thank you!
@Medelcartelinc ·
Oh wow, you are absolutely right @albert-mueller! My apologies, I had completely forgotten about that!
I just checked my permissions and I do indeed have Write access. Honestly, the reason I've been doing Pull Requests all this time is out of respect for your workflow and your
mainbranch. I prefer using my own fork to submit PRs so I don't accidentally push a breaking change directly to your codebase without you having a chance to review it.I'd prefer to keep it this way so I don't disrupt your flow! I'll only use the Write permissions in case of a true emergency.
As for the release, please take your time! There is absolutely no rush. Whenever you have some free time, you can just merge the PRs and draft the beta release yourself. Thanks again!
@gandolf243 ·
@albert-mueller, here are some great tips for creating a fully signed app, it thought you needed a payed dev ID!
These GitHub Actions secrets should contain the following values:
The exact Developer ID Application certificate identity, usually:
Find it with:
Example:
Use the entire line as the secret value.
The exact Developer ID Installer certificate identity, usually:
Find it with:
Example:
Again, store the entire identity string.
Your Apple Developer Team ID, for example:
This is the 10-character identifier in parentheses in your certificate identities. It is also available in the Apple Developer account membership details.
ORG_MAC_NOTARIZATION_APPLE_IDThe Apple ID email address associated with your Apple Developer account, for example:
ORG_MAC_NOTARIZATION_PASSWORDAn app-specific password generated for that Apple ID—not your normal Apple ID password.
Create one at:
Sign in, open Sign-In and Security, choose App-Specific Passwords, and generate a password such as:
The certificate identity values are not passwords, but the corresponding signing certificates and private keys must also be installed or imported on the GitHub Actions runner. A typical setup additionally needs secrets containing an exported
.p12certificate and its password, unless the workflow obtains them another way.@Medelcartelinc ·
Hi @gandolf243,
Yes, the AI is actually correct! Generating those
Developer IDcertificates and using Apple's Notarization service strictly requires a paid $99/year Apple Developer account.However, we don't really need to worry about that for now! We can simply keep doing what we are currently doing: building the app using the
Build-Project.commandbash script. If no developer identity is provided, the script automatically skips the signing and notarization pipeline and just builds the.appand.pkgperfectly fine.Users will just have to right-click -> "Open" to bypass Gatekeeper, which is completely acceptable for these beta builds! So if Albert doesn't have a paid developer account, this method works just fine for the time being.
@gandolf243 ·
yah, just found that out… wish I had looked back here first!
@gandolf243 ·
Sorry, I got the release drafted, but my mac is so old that the assets are taking awhile to upload.
@gandolf243 · · bearbeitet
@albert-mueller, I am sorry, I forgot to update the changelog and I forgot to update constants.py before I published the release. I will fix that now.
@gandolf243 ·
hey @albert-mueller, I invited you to help me work on the future documentation for OCLPT2
@gandolf243 ·
@Medelcartelinc, I just invited you to the OCLPT2 documentation repo.
@gandolf243 ·
@albert-mueller, @Medelcartelinc I just fixed the kernel panic. I added the Acidanthera
RestrictEvents.kextinto the payloads and separated the two versions by adding arestrictevents_t2_versionandrestrictevents_t2_pathtoconstants.pyand integrating them intomisc.py@gandolf243 ·
correction, I didn't fix the issue, I don't know why. I don't have verbose because for some reason the settings plist got wiped and I thought it was still there so verbose didn't get turned on.
@albert-mueller ·
Ok, I reverted back your commit to fix this.
@gandolf243 ·
@albert-mueller, No, nothing is wrong with my commit, the OCLPT2 settings plist (that has the stored setting that when I build OC, I want to use verbose)
@gandolf243 ·
@albert-mueller, I reapplied my commit because
@Medelcartelinc ·
@albert-mueller @gandolf243
Hey guys, I have some great news! I just opened PR #342 to officially fix the boot loops and kernel panics that were occurring on T1 Macs.
I took the app back to the old stable logic while maintaining all the latest updates and fixes. Here is what I did:
RestrictEventskext is highly experimental and was causing regressions, so it is no longer injected automatically on T2 Macs.Allow Experimental T2 RestrictEvents Kext. T2 users must explicitly opt-in to test it.RestrictEventsjust like they did in the old stable versions. This officially fixes their kernel panics (for older non-T1 Macs, the standard kext is injected normally as well).@gandolf243 ·
@albert-mueller, I was looking at the T2 forum on macruors an I saw that deeveedee has give some advice that has influenced this fork, I think you should add them to the README credits.
@albert-mueller ·
In the credits of the README it already says this:
MacRumors and Unsupported Mac Communities
Endless testing and reporting issues
@albert-mueller ·
@gandolf243
@albert-mueller ·
Isn't this actually the exact same thing?
@gandolf243 ·
@albert-mueller, you are correct. Sorry about that.
@Medelcartelinc ·
Hey @albert-mueller , sorry for being a bit absent these last couple of days. I’ve also sent Gandalf a message to explain the situation.
My girlfriend is leaving in a few days to work abroad for a year, so right now I’m trying to spend as much time with her as possible. I also took a little break to step back and think about the projects, because honestly, some things are starting to feel quite strange to me.
The main thing I’m trying to understand is why everything works properly on my Mac, while other people are having completely different results. I don’t want to just keep throwing fixes at the problem — I really want to understand what is actually causing it and find the best solution possible.
Even when I’m working at the hotel, I’m still keeping an eye on things and thinking about possible solutions in my head, so when I get a break or finish work, I can immediately sit down and try things. I’m basically trying to make the most of whatever free time I have.
I’m doing my best, but sometimes the expectations from people can be a little overwhelming. I understand that everyone wants things to work, but at the end of the day this is still a hobby project that we’re working on in our free time.
I should be active again tomorrow afternoon.
Anyway, I’ll sit down tomorrow and get back into it properly. I really want to figure out what’s causing the differences between systems and hopefully get everything working for as many people as possible.
Hopefully, in the end, we can make this work and bring a little happiness to people with it haha. That’s really what I’m trying to do.
@albert-mueller ·
Hi, @Medelcartelinc ! I wish you best wishes to your girlfriend and wish her to be happy with her new job!
@Medelcartelinc ·
Hey guys @gandolf243 @albert-mueller , I’ve been thinking about the current situation and I have a possible idea that might help keep things cleaner and avoid confusing the T1 and T2 implementations.
Maybe it would be better to keep the T1 MacBook models — especially MacBookPro14,1, 14,2 and 14,3, along with the other T1 machines — inside the Developer Mode, while keeping them outside of the main T2 application logic. This way, the T1-specific code and patches would be more isolated and we wouldn’t risk changes made for T2 affecting T1 systems.
At the moment, quite a few people seem to be having problems related to this, and I’m wondering if part of the issue could be that the two implementations are becoming too intertwined.
Another possibility is that I make a separate fork focused specifically on T1, rather than continuing to work directly on the T2 fork. It might make development and testing much cleaner and potentially make the whole project more stable.
What makes this especially strange to me is that everything works correctly on my MacBookPro14,3. I’ve tested it repeatedly and the whole setup works on my machine, so I’m trying to understand why other systems are behaving differently. This makes me think there may be some underlying issue that I haven’t identified yet.
I’m going to investigate it properly before making any major changes. I don’t want to introduce another fix that accidentally creates problems for T1 while trying to solve something else.
So I’m thinking that separating the T1 implementation more clearly from T2 could be worth trying. Let me know what you guys think.
Please let me know if you received this message and the one before.
@albert-mueller · · bearbeitet
@Medelcartelinc I think it might be better to leave 2 separate RestrictEvents, one for T2 and non-T systems and a separate one for T2 Macs. As such, a change that may make a T2 Mac working and booting to the desktop doesn’t risk a non-T2 Mac to stop booting altogether.
And also something worth suggesting: separating the T2 logic from non-T2 one via a seperate functions and strict checking if it injects on the intended target or not. What I mean is let’s say you have to inject SMBIOS profiles but the profiles for T2 Macs are different than the ones for non-T2 Macs. Seperating them with something similar to this:
def smbios_profile_for_t2(self):
T2_MACS={“MacBookPro16,2”, “Macmini8,1”, etc}
and then check it against the list:
if self.model in T2_MACS:
here, execute T2 logic
else:
here, execute non-T2 logic
And at this point, there is no longer any chance the wrong logic gets injected - it’s checking the SMBIOS very strictly. And as such, it also makes it very hard for attackers to escape the checks to inject the wrong patches.
What do you think about this, @Medelcartelinc ?
@albert-mueller · · bearbeitet
I found a bug here:
if smbios_data.smbios_dictionary[self.model]["CPU Generation"] >= cpu_data.CPUGen.ivy_bridge.value:
if self.constants.detected_os >= os_data.os_data.tahoe:
logging.info("- Blocking ACPI_SMC_PlatformPlugin on Tahoe to fix thermal conflict")
self.config["Kernel"]["Block"].append({
"Arch": "x86_64",
"Comment": "Tahoe: Block ACPI_SMC_PlatformPlugin to fix X86PlatformPlugin conflict",
"Enabled": True,
"Identifier": "com.apple.driver.ACPI_SMC_PlatformPlugin",
"MaxKernel": "",
"MinKernel": "25.0.0",
"Strategy": "Disable"
})
The issue is that Macmini8,1 is cpu_data.CPUGen.coffee_lake.value and will block the ACPI SMC Platform Plugin. However, T2 Macs have completely different power management and blocking this driver would cause issues, I even wondered how my 2018 Mac mini hasn't panicked when trying to boot the installer. I just fixed this in the source code, but before I can confirm this is the issue, I'll test this on my Mac mini 2018 later today. And if this fixes the issue, I'll roll out an update to include this change.
@Medelcartelinc @gandolf243
@Medelcartelinc ·
@albert-mueller I completely agree with your approach. Enforcing strict SMBIOS checks (if self.model in model_array.T2Macs) is exactly the kind of isolation we need to prevent T1 and T2 patches from stepping on each other's toes. I'll make sure any future PR I submit adheres to this pattern.
Also, regarding the Language Selector freezing issue on T2 Macs: I was analyzing the codebase and noticed that AMFIPass.kext is currently commented out in efi_builder/misc.py (around line 517, marked as temporarily disabled for testing the AMFI stall). Since we removed the custom boot arguments (like amfi=0x80 or amfi_get_out_of_my_way=1), the system now boots with AMFI strictly enforced. I suspect the Language Selector is freezing because the injected USB/SPI kexts for T2 are being blocked by the strict AMFI checks in the installer environment, leaving the user with no keyboard or mouse input.
Should we try re-enabling AMFIPass.kext or injecting a less aggressive boot-arg (like amfi=0x80) specifically for the installer phase to see if it brings the USB/SPI back to life?
@Medelcartelinc ·
Hi @albert-mueller,
Good news! I've been doing a deep dive on why the macOS Tahoe installer is freezing at the language selector specifically on T2 Macs, and I found the missing puzzle piece.
As you know, we recently temporarily disabled AMFIPass.kext for T2 models to debug the kernel panics ("AMFI stalls"). The problem is that OCLP natively strips amfi=0x80 from the boot arguments to ensure Apple Account compatibility. Since AMFIPass is now disabled and amfi=0x80 is stripped out, the installer boots with strict AMFI enforcement! This is causing the strict installer environment to completely block our injected USB/SPI input kexts, leaving users with dead keyboards and trackpads.
To fix this without breaking the T1 logic, I've pushed a commit to my fork that completely isolates this behavior:
It explicitly injects amfi=0x80 in the T2 _t2_handling boot-args.
It wraps the amfi=0x80 cleaning code (in security.py and build.py) with if self.model not in model_array.T2Macs:, leaving it untouched for T2 Macs.
This way, the T1 Macs are completely isolated and keep using AMFIPass.kext, while T2 Macs avoid the AMFI stall but keep amfi=0x80 injected to bring the installer's USB/SPI ports back to life.
Can you pull the latest commit from my fork, build the .pkg, and test it on your Mac mini 2018?
@gandolf243 ·
Hey, @Medelcartelinc @albert-mueller Sorry I haven't been here lately, my internet shut down an it was a mess working with the person in charge and getting it fixed, I was trying to update my self, but I decided to just jump in after I had 37 out of the 80 some odd emails left to look over! also I am recovering my Apple Account hookup on my mac after SMBIOS spoofing to macbookpro16,1. It will take me a bit to catch up, but I a ready to jump back in!
@gandolf243 · · bearbeitet
@Medelcartelinc @albert-mueller, I would like to just let you know that if there are some weird typing errors that I make that is because my built-in keyboard doesn't work very well any more. (I am actually banging on it right now so that it doesn't miss any letters.) it is specifically the d, m, h, g and e key that are the worst. Sorry, doing my best.
@Medelcartelinc ·
@gandolf243 No worries at all about the typos!
Actually, I had this exact same problem with the Apple Keyboard on my Late 2013 iMac. I thought the keys were physically dying and I had to bang on them too, but it apparently turned out to be a software/driver issue rather than a hardware failure! The keyboard itself actually works fine, it just acts up randomly because of something glitching in the OS.
So don't worry about it at all, we can definitely read through the typos! Just do your best and take your time.
@gandolf243 ·
@Medelcartelinc, thanks! I will test the keyboard on High Sierra at some point to see if it is a driver issue. (if it is, I do think it is unfortunate that issues with the software get taken out on the hardware, but that is an advantage to Apple produces, the software integrates so well with the hardware that you never get that issue, and if you do, the hardware is built so well that it isn't affected the majority of the time!)
@Medelcartelinc ·
@gandolf243 actually just updated my own system to macOS Sequoia 15.8 and the keyboard is working perfectly fine for me now! That definitely confirms it was just a macOS software glitch. Since you are testing on Sonoma right now, you might still experience the bug, but at least you know your hardware isn't actually broken so you don't need to replace it!
@gandolf243 ·
@Medelcartelinc, interesting, I still think some of it is a keyboard problem (mainly because the e key wasn't working on High Sierra) but thanks anyway!
@gandolf243 ·
@albert-mueller, do you remember how we couldn't get the statistics scrollbar that to work so we just put in a
wx.ScrolledWindow? well, the issue was that we (or me, I don't remember) had hard-coded thetextctrlto be to big, so the scrollbars where hidden, but when you resized the App settings, it got too small so I was able to fine tone the size to fit just right!@gandolf243 ·
@albert-mueller, I know this is a little late, but I did add the liquid glass icon to all the PKGs, not just the AutoPKG, not important, but I just wanted to make sure that you knew.
@gandolf243 ·
@albert-mueller, just so you know, your macrumors thread has some one waiting who wants to help with testing, they have a fleet of Macs that would be cool to get feedback on.
@gandolf243 ·
@albert-mueller, just so you know, you are still using the DEBUG build of the Privileged Helper Tool, you want to recompile it with
make release, If you are still using the DEBUG build, it can still be used say from the command line:or from malware. But I would just leave it where it is, the App isn't signed, So it would be useless.
@albert-mueller ·
The app is now signed with a self signed certificate and is no longer using the Debug build since alpha 18.1.
@gandolf243 · · bearbeitet
@albert-mueller that is not true. According to my tests, I was able to run code through it from the terminal, I also looked at it in Ghidra and I couldn't find the release logic, only the DEBUG logic, here is a video to prove it:
Screen Recording 2026-09-19 at 20.14.51.zip
Sorry for my outburst.
@albert-mueller ·
Ok, I thought I was running the release logic, not debug.
@albert-mueller ·
Sorry for that, but I really thought I was running the release version, not debug, @gandolf243
@gandolf243 ·
@albert-mueller, you are fine! I meant to look into that as I saw that the source builds weren't falling back to the password dialog, but I kept forgetting about it. as I said, you can build the release using
make releaseand then rebuild OCLPT2, test it on your mac and then go ahead and send it off.NOTE: I am 99.99% sure that it won't work on the release. In order to sign a app, you have to have a paid apple Developer Account. Which you nor me have.
@gandolf243 ·
@albert-mueller, I don't have time at the moment, (if you haven't fixed in it a hour or so I will) but no one will be able to use OCLPT2 because you forgot to update the Version Number!!! that is a disadvantage to auto updating that I hadn't thought of.
@albert-mueller ·
Fixing this bug and immediately pushing an update for this. I made a mistake not to update the version in constants.py. Now I fixed that bug.
@albert-mueller ·
Just pushed the next release immediately. While I was testing I also got hit by this bug. And right after, I rushed to fix the issue as soon as possible.
@gandolf243 · · bearbeitet
@albert-mueller, Just so you know, I am going to try and reduce the chance of this happening in the future. There are two ways for me to do this, so you choose which one you want
which one? The custom runner would require so setup, but I can show/tell you how it would work if you are interested!
the advantage to a runner is that it would generate the assets for us after we hit release.
@albert-mueller ·
I think it's a lot better to compare if the commit is newer than the previous version, not just pure version number comparing. If it only compares the version, an attacker could claim there is a newer version.
@gandolf243 · · bearbeitet
@albert-mueller, I had stuff prepared for what ever option you want! I got a runnner workflow setup and I am working on a if statement, where it takes into account the the runner. If the on device version is less then the remote version and the assets haven't been uploaded yet, it fixes the version, if the version equals the latest remote version AND there are no assets it just continues. if non of the above are true, is prints "The App couldn't be generated because the version is mixedup" and stops with
sys.exit(3). However, you can bypass this error by passing--ignore-releasetoBuild-Peoject.commandWhat do you think? Also, what about the custom runner? it would automate releases so much more, and it would try to generate releases for each commit or pull request! The cool thing is that if you want to have space, you can set a expiration date on theses commit/pull request generated resources.@albert-mueller ·
I don't think generating releases for each commit is a good idea - they may contain bugs and would make the Actions cluttered with buggy builds that no one has tested them whether anything works at all.
But I think the thing with the remote version comparing that you mentioned is a very good idea, and I would even recommend this.
@gandolf243 · · bearbeitet
@albert-mueller, the builds only get uploaded if the build logic runs without errors. this would also be a good way to test pull requests without building them locally, (though if we use custom runners, they will still be built locally, but will be uploaded for everyone to see) And, you can go though the actions tab and delete the old workflow runs.
This would make it easier for us to give someone a beta build if they need a new feature we haven't released yet.
@albert-mueller ·
I was thinking of this: #396
@gandolf243 ·
@albert-mueller, I have a workflow ready to push, do you want to do the custom runner that can build the releases and build betas?
@Medelcartelinc ·
Hey @albert-mueller,
I've been looking deeply into the mpo_policy_init for ASP (Apple System Policy / EFFACER service) hang on T2 Macs booting Tahoe.
We are currently stuck in a Catch-22 caused by how Tahoe handles AMFI on T2 systems:
The Installer Freeze: AMFIPass.kext currently fails to hook the AMFI policies inside the macOS Tahoe BaseSystem (the installer environment). This leaves AMFI strict, which blocks the internal SPI keyboard/trackpad drivers, causing the Language Selector freeze (Issue #289).
The ASP Hang (This Issue): To fix the installer freeze, we previously used amfi=0x80 to completely disable AMFI (in PR #376). While this successfully makes the installer keyboard work, when booting the actual installed OS, the T2 chip's Secure Enclave tries to initialize Apple System Policy, realizes AMFI is completely dead, and deadlocks the kernel at mpo_policy_init for ASP (Issue #392).
There is no single EFI configuration that seamlessly fixes both environments for T2 Macs on Tahoe. I propose we choose one of the following two routes for the project:
Option 1: Prioritize the OS (Revert PR #376) We restore AMFIPass.kext and use -amfipassbeta natively. This guarantees the installed OS boots without the ASP hang. For the installer phase, we simply add a note to the documentation: "T2 Macs MUST use an external USB mouse/keyboard during the macOS Tahoe installation, as the internal trackpad will not function until the OS is fully installed."
Option 2: Add an "Installer Mode" GUI Toggle We add a checkbox in the OCLP-T2 settings (e.g., "Build for USB Installer (T2)"). If checked, the app builds the EFI with amfi=0x80 so the trackpad works during install. Once macOS is installed, the user unchecks the box and rebuilds the EFI with -amfipassbeta to the internal SSD to fix the OS boot.
@albert-mueller ·
Only the MacBook Pro that this guy reported on gets stuck at this phase. On my Mac mini, it gets stuck directly at bufattr_get_apfs:9429: Volume not mounted.
@albert-mueller ·
@gandolf243 I have a question: Dortania says that when you run Priveleged Helper Tool as Debug, an attacker could execute arbitrary commands, which is not really true - it can be fixed by if running a Debug build, to run only trusted commands and nothing else. Do you know how to do this?
@gandolf243 ·
Hey @albert-mueller and @Medelcartelinc,
things with my internet connection aren't going so well right now, I am currently talking to you through a friend's HotSpot.
I hope to get back on soon and continue to develop with you guys. As for now, I can only hope for the best. I need to look into stuff and see if there is a way I can fix this issue or if I will just have to live it out.
Sorry for my sudden exit last Sunday, it was unintended.
By the way, I am sending this using Matteo's
post_comment.pyand I noticed that I (gandolf243) created disccussion 243!Below are somethings that I have noticed while I was offline:
And, why are we still using AI generated code? I thought that was too unstable and that is why we stopped. I will admit that do use it, but only to fix bugs, and somtimes I just revert it afterward.
@albert-mueller ·
I haven't made new SHA256 workflows, the new ones are for completely different stuff. The one for SHA256 is actually the old one.
@gandolf243
@albert-mueller ·
I locked the discussion to ensure only collaborators can comment, as it is intended only for collaborators. That doesn’t affect anyone, as both of you, @gandolf243 and @Medelcartelinc are collaborators anyways.
@gandolf243 ·
Hey, @Medelcartelinc, @albert-mueller I am back!!!!!!! I am working on uploading the branches that have all my changes in them and creating pull requests, though non of my changes are ready for the upstream, we can still work on it together!
@gandolf243 ·
@albert-mueller, I am glad that I was too busy to much more, because the code that you merged doesn't have any know issues, you just got the Security fix that I told you about in the pull request. there is just one thing that I need to add, and then it is ready for a release. but, as I said we should stick to the branch until everything in
plan.mdis done.@gandolf243 ·
@albert-mueller, I would check and make sure that your dark mode icon isn't broken.
@gandolf243 ·
it looks file
@gandolf243 · · bearbeitet
correction: the logic looks fine, but the icon doesn't look good. It wasn't touched by Icon Composer, coolkid just ran it through a filter. I have been trying to get up to Tahoe for months so that I can create a good dark mode icon and improve on the other icons. plus, unless you have tested it, I don't think it will show up in the dock.
@gandolf243 ·
@albert-mueller, when you release the next 3 or 4 updates, include this banner a the top of the description:
@albert-mueller ·
I just viewed this and added this message.
@Medelcartelinc ·
Hey guys I am here too. I recently moved houses and it was a bit destructive getting back to work but I am back now.
@gandolf243 ·
@Medelcartelinc good to see you back!!
@albert-mueller ·
@Medelcartelinc good to see you back!!
@gandolf243 ·
@albert-mueller, in the release that you just put out you forgot to put in the banner and (you might not have known about this) I had changed the exstraction logic so hat it doesn't require a static 45GB after downloading the installer, it just requires the about amount that the installer will take up.
@albert-mueller ·
I also had forgotten to remove the popup where it says to enter the Universal-Binaries.dmg instead of the user password (which was just a warning designed for those earlier versions where it really asked to), and in the source code I deprecated this popup to ensure no confusion. An entire issue has been opened because of this confusion: #465 .
@albert-mueller · · bearbeitet
@Medelcartelinc I'm working on an option when building the app, to explicitly switch the update channel for everyone using your build, but you'll need to pass the --update-channel=medelcartelinc --ignore-releases flags. The --ignore-release flag is to ignore if I already released the release that you're currently releasing to avoid getting blocked while building the app. The --ignore-release flag is nothing new, it's there since early alpha 19 releases.
The goal is users can remain on your version and not ending up every time I release a newer version than yours, users to end up switching forks because of a forgotten setting.
@Medelcartelinc · · bearbeitet
@albert-mueller That's a fantastic addition, thank you!
It will definitely make testing and distributing custom builds much easier. Using during the build process to lock users onto the fork's update track is exactly what we need to prevent accidental upstream overwrites while we are testing experimental features. I'll make sure to start using those flags as soon as they're merged into the builder. Thanks for implementing this!
@gandolf243 ·
@albert-mueller, there was this person on macrumors who had gotten their macbook9,1 up to tahoe with full graphics, and practically no root patches. I invited them to send there hack over here via pull request.
@gandolf243 ·
@albert-mueller, jazzzy just updated the macos-next branch with tons of patches, this is just a idea, but they might have finished support for tahoe. But, they are at least coming in fast! I think we might need to do some updates.
Accually, I think there is sill a long way to go based off of the commits I am seeing.
@albert-mueller ·
Yes, there is still a very long way ahead of them.
@gandolf243 · · bearbeitet
@albert-mueller, should we bring in some of their patches or are they too old?
@gandolf243 ·
@albert-mueller, have you seen this??? Dortania is releasing RCs!!! 3.0.0 RC 1 I think they are very close to getting Tahoe supported. They could also be doing this to keep there user with them and not us!
@gandolf243 ·
Hey @albert-mueller, you missed it, some one got a macrumors account just to accuse us of stealing free software! (i.e, OCLP)
@albert-mueller ·
@albert-mueller ·
Can you check in your MacRumors if that person still appears?
@gandolf243
@albert-mueller ·
@gandolf243 And did it only sent to you?
@gandolf243 · · bearbeitet
@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
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, I think it was this post (which you can't see any more because I deleted it)
@albert-mueller ·
@gandolf243 just fixed this and migrating away from my own PatcherSupportPkg. It's already spelling trouble for them and us if that's OK for them?
@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 ·
@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 ·
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?
@albert-mueller ·
I think on that one there is a Metallibs API
@gandolf243 ·
Yes, I could modify it to also host the docs. does that sound good?
@albert-mueller ·
Yes
@gandolf243 ·
Ok, I will do that soon. I will of course need to do some heavy modification of the existing web interface.
@gandolf243 ·
@albert-mueller, I am sorry to report that it took way longer then I thought to get your repo cloned locally. I am pushing the changes. If you are wondering about the time gab that is because I was trying to get GitHub Copilot to work. It didn't. I am having so many issues syncing VS Code to GitHub. What my Plan was was to get the website into English so that I can read it and then change it to have a local copy of the docs folder. there is still some stuff that needs to get fixed, but I am very close to getting it done. I know that it is 8 o'clock for you, but for me it is 1 o'clock. So I am going to bed. See you in 9-10 hours.
@albert-mueller · · bearbeitet
Ok, see you in 9-10 hrs!
@gandolf243 ·
@albert-mueller, I am just going to wipe all the website stuff except the Metallib part.
@gandolf243 · · bearbeitet
@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.ymlyou uploaded. You were super close! There were just two small details keeping it from running properly:docsfolder uses VitePress, so the build output lands indocs/.vitepress/dist/(not.vuepress).albert-meullerinstead ofalbert-mueller).Here is the clean, un-commented workflow you can drop into
.github/workflows/build-site.yml:@gandolf243 ·
@Medelcartelinc, there is a issue, dortania has a environment that they are using. We don't know what that has:
@Medelcartelinc ·
@gandolf243 Don't worry at all, that's not a secret or custom environment!
In GitHub,
github-pagesis 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-pagesenvironment for the repo.. The step
actions/deploy-pages@v4handles 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
environmentblock 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 · · bearbeitet
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 · · bearbeitet
@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.ioone.@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 · · bearbeitet
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:
@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 · · bearbeitet
Medelcartelinc#27
@Medelcartelinc Pushed this PR request to main