@deeveedee
This is an interesting topic. Since OCLP and OC are open source projects I don't think they would intentionally hard code any malicious code into their bootloader and their patcher and besides no one is forcing people to use their bootloader and their patcher we all use them at our free will (including myself)
But I would like to know more about that report thingy for sure and know what kind of information is being sent to Dortania, I'm almost sure it's not reporting my banking information but still it would be nice to know what's exactly being reported.
On another security note disabling SIP and AMFI alone can open up your computer to all sorts of nasty attacks you can read about it here which is a requirement for installing Sonoma.
This thread is about making users aware of the security limitations of OCLP and about requesting changes that make the end user aware of the security limitations.
I don't think a thread on MacRumors is the way to request changes. I doubt the OCLP developers read much (if anything) in this forum. It is certainly not the place where they discuss changes.
@deeveedee
This is an interesting topic. Since OCLP and OC are open source projects I don't think they would intentionally hard code any malicious code into their bootloader and their patcher and besides no one is forcing people to use their bootloader and their patcher we all use them at our free will (including myself)
But I would like to know more about that report thingy for sure and know what kind of information is being sent to Dortania, I'm almost sure it's not reporting my banking information but still it would be nice to know what's exactly being reported.
On another security note disabling SIP and AMFI alone can open up your computer to all sorts of nasty attacks you can read about it here which is a requirement for installing Sonoma.
That’s also why personally I’m a big supporter of enabling SIP as much as possible: as I’ve said many times, with OCLP’d Monterey on a Metal-capable Mac, you could optionally enable SIP fully and leave only the SSV (signed/sealed system volume) disabled (0x800); but that changed in Ventura and Sonoma (0x803 still mandatory: otherwise, with increased SIP, either the window server will crash or the system won’t boot): so, it would be interesting if the devs researched middle/long-term possibilities to enable SIP further also in the two latest macOSes - as they also said themselves in a release note some time ago (that statement was subsequently removed, so it’s unclear if they still pursue this goal)…
(BTW, AMFIPass was a great achievement, which previously seemed almost impossible to reach.)
I don't think a thread on MacRumors is the way to request changes. I doubt the OCLP developers read much (if anything) in this forum. It is certainly not the place where they discuss changes.
You've assumed the Devs aren't continually watching this thread. While this may not be a way to formally request features/changes via proper channels, they are watching this very closely.
EDIT: I'm not yet sure if their monitoring of this thread is out of curiosity or because of genuine interest. While it would be nice to get their responses, any comment by a Dev in this thread would only attract attention to this thread and lend credibility to it. We're not there yet.
At this time, I am being very careful to keep this thread fact-based (as much as I can) and my posts accurate, because any early Dev responses are likely to be to pounce on inaccuracies in order to damage this thread's credibility. I wouldn't be surprised if some or all Devs still think this thread is an attack piece instead of the constructive discussion that it is intended to be.
EDIT2: Devs, I know you're chess players. And I sincerely mean that in a good way.
@deeveedee
This is an interesting topic. Since OCLP and OC are open source projects I don't think they would intentionally hard code any malicious code into their bootloader and their patcher ...
How simple and easy life would be if we only needed to concern ourselves with intentionally malicious code. Mistakes/bugs that expose vulnerabilities are what we're primarily focused on. And we need to think bigger than the mistakes that can be easily seen / discovered via a code review (no matter how thorough). In fact, a code review is unlikely to find flawed architectural issues that can be exploited by hackers. Such vulnerabilities require extensive testing by experienced personnel with advanced systems. Think Apple's release of each certified, SEALED macOS.
When you have time, read from the beginning of this thread.
Decided to make a new account with a proper identity since I ended up being here longer than I thought and it didn't feel right using the old account. To confirm, yes at least couple of us are monitoring the threads here and there. There are couple developers taking part in the discussion in the main "Unsupported Macs" thread.
Since I am here, might as well bring some more clarity for few more things.
Firstly, RSRs unfortunately are never going to be supported on pre-Haswell models because this is a hardware limitation. We have to restore support for non-AVX2 systems using a cryptex from Rosetta 2, without this move non-AVX2 would be dead entirely as both Ventura and Sonoma only support x86_64h and thus kernel panic on boot without the cryptex. The fact this method was found was honestly a big surprise for the team back when Ventura was being worked on, at first the life of non-AVX2 looked grim.
The fixes RSRs include will be in the bigger .X updates later, as used to be the case before them. Also according to fairly recent research by the lead dev, RSRs don't really patch kernel exploits which would in most cases be most critical. This is why there's also been a low amount of RSRs.
That’s also why personally I’m a big supporter of enabling SIP as much as possible: as I’ve said many times, with OCLP’d Monterey on a Metal-capable Mac, you could optionally enable SIP fully and leave only the SSV (signed/sealed system volume) disabled (0x800); but that changed in Ventura and Sonoma (0x803 still mandatory: otherwise, with increased SIP, either the window server will crash or the system won’t boot): so, it would be interesting if the devs researched middle/long-term possibilities to enable SIP further also in the two latest macOSes - as they also said themselves in a release note some time ago (that statement was subsequently removed, so it’s unclear if they still pursue this goal)…
(BTW, AMFIPass was a great achievement, which previously seemed almost impossible to reach.)
Full SIP with root patching is pretty much impossible, Monterey was fine because Apple actually left most of the drivers in despite dropping some of the models. This meant machines like the MacBookPro11,1 could run it without root patching. To mitigate it the best we can, we only disable the parts of SIP that are needed for root patching to work.
Also to touch on the "Russian warez" claim, as far as I know none of the developers in OCLP are Russian.
For the analytics: What we collect is the model, macOS version, app version, what GPUs are in the system and firmware vendor to see whether it's a real Apple system or a Hackintosh. It's purely for figuring out what models are being used the most and whether issues apply to one model or more broadly, what version(s) of OCLP are affected (is there a regression, is it caused by a new macOS update or has it always existed?), also to filter out Hackintosh reports as we don't care for them.
If you want to run macOS on unsupported hardware, stop using OCLP and document in separate threads for each unsupported Mac what changes are needed to make it work. This is the way.
This is making sense and goes very well with the "less is more" philosophy with regards to patching that was very common in the earlier "unsupported Macs" threads by dosdude1 and others. For example it does not seem to take much in order to run Big Sur or Monterey "natively"(without OC) on a Mid 2012 MBP and it would be great to have these minimal "adjustments" documented somewhere.
At the same time I am humbled by and understand that it is very difficult to create a product for mass consumption that is very easy to use and where you would not have to answer thousands of emails a day with very basic questions.
@deeveedee
I did read the posts from the start and I've read them again just in case if I've missed anything.
Voicing a concern is one thing and it is going to raise awareness which is a good thing, but at the same time it might create chaos and lead to paranoia.
I have a question that you might have an answer to: Since all computers are open to attacks and getting hacked (for instance Apple's iCloud service got hacked few years back and tons of data has been stolen) if a computer got hacked how can we make sure that using OC or OCLP was the root cause for that?
I know disabling SIP and AMFI and using 3rd party and unsigned kexts can lead to serious security risk and I grant you that but as we're all well aware, most of the times negligence on the user's part is the reason they get hacked regardless of the computer or the operating systems they're using.
I'm just simply curious to know how to determine that the OC was the reason they've got hacked.
Welcome to the conversation and thank you for joining us! Thank you for addressing some of the issues. Looking forward to continued civil discussion and to your assessment of the other issues / requests in this thread.
@deeveedee
I did read the posts from the start and I've read them again just in case if I've missed anything.
Voicing a concern is one thing and it is going to raise awareness which is a good thing, but at the same time it might create chaos and lead to paranoia.
Some of us here are focused on fixing issues. I personally am of the belief that they are unlikely to be fixed and am focused on getting OCLP docs and messaging to clearly state that the vulnerabilities exist, that an OCLP-patched Mac is not as secure as unpatched, fully-supported Mac (along with a list of known limitations) and that users are accepting risks by using the software.
I also think that the warnings may need to be model-specific (e.g., this model will not receive Apple RSRs).
I believe that chasing solutions to individual vulnerabilities (like SIP) just takes us down a rathole (for me) and will leave that for others to champion.
My requests, while highlighting the known limitations, have always been intended to drive OCLP / Dev transparency.
Welcome to the conversation and thank you for joining us! Thank you for addressing some of the issues. Looking forward to continued civil discussion and to your assessment of the other issues / requests in this thread.
For the requests, there's not much for me to comment on as the team leaders make the decisions. However I know they are at least aware of them. I just try to bring clarity for things the best I can.
Honestly I think nagging the user constantly in every reboot and every menu would get annoying fast. If it were just up to me, I could probably compromise on having a notification when launching the app or alternatively when installing root patches but constant nagging would get old. As an example, people hate when Windows nags them for multiple things. When it becomes an annoyance, people kind of stop caring about the intent and just want it to go away.
OCLP already does notify about root patches being wiped after every update, which is indicative of it being installed in cases e.g. someone buys an OCLP'd Mac without knowing. This is also one of the reasons why we heavily discourage everyone of selling Macs with OCLP installed and would much prefer them to be sold on native OS but maybe having the customer hinted about the existence of OCLP, so they can decide for themselves whether to use or not use the app.
You also mentioned about the drivers being "frozen in time", yes that is true. However, that is also the case if you keep using the native OS of a dropped system, in both scenarios Apple won't fix them. Older OS's (depending on how old) also won't get *any* security patches while newer versions running via OCLP typically can get them. It ultimately becomes a choice whether you want new features (sometimes with limitations) and support for modern applications or not.
Just to clarify a little… The Mac I ran with SIP normally (except of course when root patching) at 0x800 on Monterey was a MBP11,3, thus with the (in)famous Nvidia Kepler dGPU, and of course root patched for that one; and so the SSV could not be enabled: but with 0x800, SIP showed up as enabled in csrutil status and everything worked perfectly! With Ventura and Sonoma, this doesn’t work anymore: while the root patching remains (and is even more comprehensive), for some reason in Ventura and Sonoma also the filesystem must remain unrestricted, otherwise the window server crashes, etc.; and untrusted kexts must be enabled, too, probably because they are more heavily modified than before. So, I was just wondering if this could be mitigated in the future, with new developments/researches…
Just to clarify a little… The Mac I ran with SIP normally (except of course when root patching) at 0x800 on Monterey was a MBP11,3, thus with the (in)famous Nvidia Kepler dGPU, and of course root patched for that one; and thus the SSV could not be enabled: but with 0x800, SIP showed up as enabled in csrutil status and everything worked perfectly! With Ventura and Sonoma, this doesn’t work anymore: while the root patching remains (and is even more comprehensive), for some reason in Ventura and Sonoma also the filesystem must remain unrestricted, otherwise the window server crashes, etc.; and untrusted kexts must be enabled, too, probably because they are more heavily modified than before. So, I was just wondering if this could be mitigated in the future, with new developments/researches…
It's been a while so my memory is a bit shoddy on that, I think it is because Ventura+ require a lot more downgrades (including Metal.framework etc) compared to Monterey and as such the advancements that we had in enabling more of SIP had to be rolled back. Monterey really was a simple release, Ventura turned out to be utter hell requiring a new tool (dyld shared cache extractor/dsce because Apple started moving on disk binaries to the cache) plus all kinds of things to be done and thus it took a long time to happen, Sonoma was easier again after the groundwork being done with Ventura. Ventura was so bad the other of the lead devs almost called it quits and thoughts of dropping non-Metal were also being thrown around.
For the requests, there's not much for me to comment on as the team leaders make the decisions. However I know they are at least aware of them. I just try to bring clarity for things the best I can.
Honestly I think nagging the user constantly in every reboot ...
In a secure computing environment, some of us are required to see the 'nagging' and have become accustomed to it. I see the airbag and ABS status lights every time I start my car (and the nagging check engine light until I repair my car or put a piece of electrical tape over it). That is why the request for warning at boot is requested to be user-configurable (and, in light of your observation, should be easily dismissable).
This might just be my product management side talking, but do you think it would help this conversation if we had a requirements matrix that evolved with our mutual input and collaboration? I would be happy to manage that matrix or you could. It is up to you. Thank you. EDIT: Or maybe you'd like to nominate a neutral party. It's a lot of work, so I won't nominate anyone else.
BTW: It just occurred to me that the 'automobile dashboard' of warning / status lights may be a great way to communicate security status in a way that is customized per SMBIOS.
EDIT: I do understand and appreciate your 'frozen in time' argument; however if my decision is between Monterey which still receives Apple updates because it is natively supported on my Mac and Sonoma which is not natively supported and must wait for Wi-Fi security updates via OCLP, I may choose to stay on Monterey (if I was alerted to the potential security vulnerability). Similar for my choice between Ventura and Sonoma. I can't make the educated/informed decision if no one alerts me to the potential risk.
EDIT2: It would not surprise me if there are many wondering what the heck I'm talking about, because they never knew this to be a risk that they accepted when they upgraded to Sonoma with OCLP.
EDIT3: ... and on a somewhat humorous note, I'm assuming you don't need me to demonstrate my admiration and respect with 'likes' of your posts 😄 I love all of them. If it relieves some pressure/burden,you don't need to 'like' all of my posts either. 😀
EDIT4: You already knew this, so I'm posting for the benefit of others. My 'Enable RSR Updates' request was never intended to actually do that (Enable RSRs on unsupported Macs). It is to create awareness among the unsuspecting users that this is an OCLP security vulnerability. My issues with OCLP are all about Dev transparency and product transparency.
For now, the unsuspecting user of impacted Macs needs to know that they are not getting RSRs to address critical flaws (no matter how infrequent). If Devs figure out how to enable RSRs for everyone, then the warning light on impacted Macs changes from RED to YELLOW to indicate that it's still a risk and not as good as the supported Mac, because the RSR depends on a vacationing Dev and not Apple.
… While the MBP11,1 - with a still officially supported iGPU and no unsupported dGPU - didn’t need any root patches to run Monterey: thus, it was almost exactly as a supported machine, with both SIP and SSV fully enabled.
Well, the topic of privacy and security is super broad. You will need to narrow this down at least a little to not argue in circles due to misinterpretation. You will need to define
1. who's your threat actor -- Apple (or their associates), OCLP (or their associates), or third party?
2. what are they after -- data you've created where it is meaningful and you're the author of it (like a document your wrote, a photo you took), your usage data (less meaningful, such as the OS version you're on, and you technically cannot get copyright on this type of data), denial of service (preventing you from using your computer), your access (your passwords to banks and such)
3. what level of access do they already have -- complete control (they write the software, and they can change the software behavior any way they want), user consented actions (like the kexts installed by OCLP which user intentionally installed), policy level control (a company administrator installing a work profile on your device), no control but can feed inputs into the software (a website displaying a WebP image, a person sending an iMessage)
4. have you consented to it and is it legal -- consent and legal (most thing laid out in privacy policy), no consent but legal (NSA authorized by law to monitor you), no consent and not legal (hackers stealing through malware)
From reading some of the later posts, I see that some of the more active members wants to discuss this in particular: threat actor is a non-Apple non-Dortania third party (a.k.a. hackers), who are interested in the user's more sensitive data, access, and files, and who would not have any privileged access to the system other than feeding some input, and the user has not consented and it is very illegal for them to take anything.
For things like Dortonia taking your usage data vs Apple taking your usage data, yes there is a difference - you can see the code what Dortonia is taking, where you don't exactly know what Apple is taking (an auditor doing penetration testing and security audits can only attest that no third party not Apple can make the software perform in ways unintended by Apple to do the third party's bidding, a.k.a an exploit, but cannot guarantee that Apple itself isn't taking the data for themselves (e.g. CSAM scans) because that isn't the auditor's job to attest that), but that difference is pretty minor because it is just usage data. And this would be an entirely different discussion vs the hacker discussion.
The more interesting part of the discussion is whether third parties not Apple or Dortonia (such as a hacker) can take advantage of the fact of a OCLP patched computer (vs a non-patched officially supported one) to steal your password/files. And as an earlier commentator pointed out, OCLP is insecure by default - it turns off a few macOS protections like verified root volume in order to do root patching (there are simply no way to re-enable some of those protections, because that is the point - Apple wants to make sure no non-Apple software can change the system without being discovered, otherwise the security feature has failed its purpose and it is a bigger problem).
If OCLP is willing to improve its security competency as much as possible, then it is indeed correct that OCLP will need to regularly distribute updates to kexts that it extracted from earlier macOS versions and injected in unsupported macOS versions. So in other words, I agree that Dortania should probably be monitoring the changes to the kexts being patched on Monterey and regularly update them in the repo.
One thing I can think of is that for stability reasons I tend to hold back feature updates (for example, I wouldn't jump on macOS Sonoma right away even if I had a supported Mac), but would love to get security updates as soon as possible. So it would be nice if OCLP can have security fix only releases where relevant without all the new features.
PS: software audits are actually not that effective. As you can see, companies go through audits but vulnerabilities are still found after an audit has been conducted and the relevant fixes have been applied. It is much simpler to attest to a presence of mistakes than it is to attest the absence of mistakes.
@RumorChaser welcome. I see your account is very new. Welcome to the discussion! All comments are welcome from newbie to 'macrumors god'
Also, we now have a Dev in the conversation so we may be able to shift focus from 'back to basics' overview to requirements. Definitely read the first few posts in this thread (including links to background posts in the Sonoma thread).
As I mentioned, I'm focused on product and developer transparency, so I personally will let others champion non-messaging issues.
EDIT: Allow me to provide one example of transparency using your post. You suggest that we can review OCLP code to see the analytics submitted to devs. This is not transparent with scope that is too limited because:
The user needs to inspect code with every submittal (code changes)
Regardless of the Dev's intent, OCLP will be adopted by users who don't know enough to think about checking the code (let alone how to check)
This is just one example that illustrates my focus on transparency and messaging.
OT: This is off-topic,but just want to say I like your User Name. 'Rumor Chaser' - Another one I wish I'd taken!
Oh - and don't underestimate the confusion that can be caused by analytics submitted from a hackintosh. Fortunately, hackintosh users can disable all submitted analytics via a 'slider' in the OCLP GUI.
… Another thought, this time about the SSV: if, in order to not break the seal, the System volume must remain intact, without modifications… would it be possible to store all patched kexts and frameworks on the Data volume (as some form of extended auxiliary collection)…? Today, some patched kexts - and similarly for frameworks - are on the System volume (in /System/Library/Extensions) and others on the Data volume (in /Library/Extensions), at least for KDK-less installs: so, in order not to break the seal, everything that is modified by OCLP would have to be relocated to the Data volume. Maybe possible, maybe not: just yet another idea…
@Sven G
I'm not sure if that would work since SSV features a kernel mechanism that verifies the integrity of the system content at runtime and rejects any data — code and non-code — without a valid cryptographic signature from Apple.
So that might not work with unsigned kexts unless those kext are provided and signed by Apple.
@Sven G I think you'd have to fork your own version for that
Slight joke aside - I think we need a separate thread which offers coding advice to developers that are operating at a high level that I have rarely seen. I think that coding and implementation advice (if even necessary) is way premature when we haven't even developed a requirements document. But that again is just the product mgr in me. If we continue that kind of discussion in a thread, we're going to lose the requirements discussion (which may or may not be the intent).
The beginning of this thread was filled with a significant amount of subjective snark, and it is hard to respond in an objective manner (this is version 3 of this response, written and edited over multiple days) when reading that. It may seem funny to you, but it hurts the people who work on this out of passion. Being disparaged for not having the capacity to do things as well as Apple does (which, arguably, Apple is not perfect at either) is not fair. It would be nice if everyone could stay focused on technical discussion, as the latter half of this thread has been.
The lead developers of OCLP are Mykola (khronokernel) and I. We do not monitor MacRumors; I only look (at a sum total of 5 threads) when I am bored or if I am told to look (which I was for this thread), I post even more rarely, and I don't think Mykola looks at MR at all anymore. So MR is not the best way to get ahold of us.
This generally isn't an issue, but I do want to clarify that Mykola and I are also the only ones who can officially speak for OCLP. Anything official needs to be endorsed by one of us. The viewpoints of contributors are not official viewpoints, and they do not speak for the project.
I don't think there's a point in this. For the most part, people using OCLP will either not understand the intricacies of the specific security downgrades required, or just not even read it and gloss over it. Others will completely misinterpret it as OCLP actively hacking your devices, which is obviously not the case. Even still, there won't even be much space in the UI to explain it beyond a sentence or two.
Instead, I think it's better to mention it in the docs - there will be more space for it, and everyone using OCLP will be reading the docs anyway.
This is not feasible. We cannot implement this at the UEFI level (we're not UEFI devs), and implementing this on something like the login screen would require patching a significant chunk of macOS (especially when our goal is to avoid patching as much as possible), for something that a significant amount of people will disable when they first see it anyway.
I don't want to get too deep into the analogy game, but it's not like macOS pesters you to add a password if you didn't set one. Many people would be pissed off if it did.
This would be a niche feature that I don't see being used often (I assume most people want WiFi to work). It's not worth spending development time on (which consists of not only the time it takes to write the code, but also to test it and ensure nothing breaks).
When "Disable Reporting" is unchecked in the OCLP GUI, provide ability to view OCLP-generated analytics before they are submitted to OCLP Developers (similar to the way crash reports can be viewed before being submitted to Apple)
What's sent is always the same, it's just a subset of what's listed in the statistics section of the App section of settings, and is only sent on launch. The specific stuff is detailed here. Crash reporting is also detailed there, although it was disabled as we kept getting too much spam from our GUI framework.
I think a good compromise is documenting what's sent in the docs.
Change wording in GitHub so that it doesn't imply that official OCLP releases are secure. As currently worded, the developer comments suggest that users should not use nightly builds because they are not safe. The unaware user may assume this to imply that the official OCLP releases are perfectly safe (from a data security / digital identity perspective)
The aim of this wording is to convey that it's possible for nightlies to break your installation/machine as they're not tested - it is not intended to make any comment on security with OCLP. I will clarify it.
Again, not feasible. We can only boot Ventura and above on these machines because we use a cryptex used for Rosetta support on Apple silicon machines. These cryptexes do not make use of AVX2, while normal Intel cryptexes do. RSRs have different contents between Intel and Apple silicon, and only Apple silicon RSRs are shipped with said cryptex.
We don't have a way of emulating AVX2, and even if we could the performance implications would make the Macs slower. We have thought about trying it anyway, but it's a significant task and none of us have any ideas on how to approach it.
It does seem like Apple has shied away from using RSRs recently though, especially since they aren't usable for kernelspace bugs.
Currently, an unaware user may read OCLP documentation with phrases like "Built with security in mind" and "Experience macOS just like before" and may assume that their Mac is just as secure as if they were to purchase a Mac that fully supports the latest macOS without OCLP-patching.
This is a fair point - as newer macOS versions have been released, more and more models have been requiring patches that require downgraded security protections, and the docs haven't been updated to reflect that. I will update the docs to clarify this, and we will add a page on security caveats introduced by use of OCLP and legacy hardware in general.
BTW: I get that one could argue that, since the Wi-Fi framework is extracted from Ventura, it is still getting updates from Apple. Ok - we still have to wait for OCLP Devs to extract the framework from Ventura and release an OCLP update with the new framework. And that only lasts as long as Apple is still supporting Ventura.
If OCLP is willing to improve its security competency as much as possible, then it is indeed correct that OCLP will need to regularly distribute updates to kexts that it extracted from earlier macOS versions and injected in unsupported macOS versions. So in other words, I agree that Dortania should probably be monitoring the changes to the kexts being patched on Monterey and regularly update them in the repo.
This is not as simple as it sounds. Updating kexts/frameworks that we've downgraded is a much bigger endeavor than most people think it is. There are a few reasons for this:
Future updates may change/break things - this is why certain kexts/frameworks are pinned to point releases in the middle (ie. 11.3) as this was the latest working version
If we update something, we now have to test on every single model that makes use of it, and version compatibilities also come into play
Some of these downgraded kexts/frameworks are patched as well
Some kexts/frameworks depend on other kexts/frameworks, and those kexts/frameworks could have the same issues
We can't backport security fixes either, Apple doesn't release the source code for frameworks and kexts. This is why pushing out any kind of security update is not simple at all.
Then there's kexts that were dropped that we add back, which we can't do anything about as Apple has simply stopped updating them.
Because of everything mentioned above (security is already compromised to begin with), updating kexts/frameworks has not been a priority for us. We will take a look to see what we can update without breaking things, but it's definitely not going to be quick.
One thing I can think of is that for stability reasons I tend to hold back feature updates (for example, I wouldn't jump on macOS Sonoma right away even if I had a supported Mac), but would love to get security updates as soon as possible. So it would be nice if OCLP can have security fix only releases where relevant without all the new features.
I'm not fully sure about what you're asking for. Do you want security updates released quicker (as a patch version update, as we're using SemVer now) without waiting to group it with more changes? Or are you asking for something else? Ideally, we would like to decrease the attack surface that is introduced with OCLP. However, this takes a lot of time, especially when we need to make sure what we're doing is user-friendly and stands up to everything users do. AMFIPass in itself took months of work (before the beta releases) of isolating what was wrong, trying various approaches in order to work around the problem, testing it to make sure it worked, fixing it because it didn't, and writing the code once it finally worked to implement it into OCLP.
A fellow contributing developer and I have been looking at ways to reenable some security protections for over a year now, and it's been slow going and we don't have anything we can share (and we don't want to make any guarantees). Even still, the likelihood that we can bring things up to the level of security that unpatched Macs have is slim, as there are too many things out of our control.
… Another thought, this time about the SSV: if, in order to not break the seal, the System volume must remain intact, without modifications… would it be possible to store all patched kexts and frameworks on the Data volume (as some form of extended auxiliary collection)…? Today, some patched kexts - and similarly for frameworks - are on the System volume (in /System/Library/Extensions) and others on the Data volume (in /Library/Extensions), at least for KDK-less installs: so, in order not to break the seal, everything that is modified by OCLP would have to be relocated to the Data volume. Maybe possible, maybe not: just yet another idea…
Everything that's in /S/L/E is in there because it can't be in /L/E - ie. GPU bundles need to be in /S/L/E because that is hardcoded. Frameworks also have to be on the root volume as well for the same reason.
@dhinakg I am going to take the time to review your response and will probably need my own revisions. There is no snark and none intended. I left that at the door for the begining of this thread.
@dhinakg I need to say this and may delete later. If I wanted to sabotage constructive criticism and attempt to deflate an opposing position, I would start by labeling the opposing view snark. Politicians do it all the time. We need to leave the personal comments in Discord. I hope you agree.
@dhinakg BTW: I understand the emotional outburst that you needed to release. I deserved that for my 'nuclear' approach to initiating this conversation. I apologize for that and understand that you and the Devs will need time to cool off (and warm up to me). Take as much time as you need, but know that I am working hard in this thread to make sure I am factual and accurate to the absolute best of my abilities. I am very open to being told that I am wrong and to being corrected when necessary. I also respect you for taking time to respond. Thank you.
@dhinakg Thank you again for your response. There is new discussion later in this thread before your response, where I replied to Neon Ball. I believe these responses contain updated info not available when you were preparing your response. I'll freeze my responses. When you have time, could you please review your response against the new info and please let me know when your response is 'frozen.' I will review and reply afterwards. Thank you.
EDIT: Let's allow this discussion to proceed at your pace based on your availability. I know you are busy with other priorities. No rush and no pressure.
EDIT2: I want to use your terminology and realize I confused a request with the word 'boot.' I mean launching macOS, not EFI, but even that is confusing.
What single term would you like me to use to describe launching macOS after OC bootpicker?
At what phase (again, learning your terminology) does OCLP check for OCLP updates (single term if possible)?
Thank you.
EDIT: Since we're in a thread that allows edits, I will try my best to designate changes to posts with EDIT or similar designators. My stream of consciousness must have been a challenge to follow.
