3 ms·

Isn't the workaround here to back up your keychain file, remove your passwords from the keychain, update to Sonoma, disable iCloud keychain, then import the bac

Isn't the workaround here to back up your keychain file, remove your passwords from the keychain, update to Sonoma, disable iCloud keychain, then import the backup? Not a trivial process, but should be easier than the author's attempted workaround of disabling SIP and installing while offline. Long term I suspect the actual answer will be that if you don't want to use iCloud Keychain then you just can't use the keychain at all, which is a shame as it once was one of the good parts of macOS.

lapcat 2y ago
> should be easier than the author's attempted workaround of disabling SIP and installing while offline Disabling SIP wasn't an issue, because I had already done it to eliminate slow app launches: https://lapcatsoftware.com/articles/2024/2/3.html https://lapcatsoftware.com/articles/2024/2/3.html On my second attempt, I managed to update without an internet connection. See the new addendum to the article.
- sunshowers 2y ago
  > Perhaps disabling System Integrity Protection disables the malware scan too? I haven't checked this, but it's not really viable for me as a Mac software developer, because I need to test the same runtime environment as my users, otherwise I could write code that works for me but not for my users. I'd be a bit careful here by the way. Disabling SIP results in other weird differences too, that may cause programs to run for you but not most of your users. For example, LD_ and DYLD_ environment variables are no longer sanitized [1] for system processes. Fun fact: the GitHub Actions Mac environment also disables SIP. So it might run for you and in CI, but not for your users. [1] https://briandfoy.github.io/macos-s-system-integrity-protection-sanitizes-your-environment/ https://briandfoy.github.io/macos-s-system-integrity-protect...
  - saagarjha 2y ago
    Wait, why? Seems like a bad thing to do in CI?
    - plorkyeran 2y ago
      I disabled SIP in our CI environment because with ~5 Xcodes installed and VM images that were reset to a baseline every day or two the malware scanning often literally didn't finish before the VM was reset and it was forced to start over, and while it was running builds took 2-3 times as long. I probably could have done something fancy where the VMs were left running a day or two before being frozen and deployed, but disabling SIP was the much simpler solution to the problem.

lapcat 2y ago

> should be easier than the author's attempted workaround of disabling SIP and installing while offline Disabling SIP wasn't an issue, because I had already done it to eliminate slow app launches: https://lapcatsoftware.com/articles/2024/2/3.html https://lapcatsoftware.com/articles/2024/2/3.html On my second attempt, I managed to update without an internet connection. See the new addendum to the article.

sunshowers 2y ago
> Perhaps disabling System Integrity Protection disables the malware scan too? I haven't checked this, but it's not really viable for me as a Mac software developer, because I need to test the same runtime environment as my users, otherwise I could write code that works for me but not for my users. I'd be a bit careful here by the way. Disabling SIP results in other weird differences too, that may cause programs to run for you but not most of your users. For example, LD_ and DYLD_ environment variables are no longer sanitized [1] for system processes. Fun fact: the GitHub Actions Mac environment also disables SIP. So it might run for you and in CI, but not for your users. [1] https://briandfoy.github.io/macos-s-system-integrity-protection-sanitizes-your-environment/ https://briandfoy.github.io/macos-s-system-integrity-protect...
- saagarjha 2y ago
  Wait, why? Seems like a bad thing to do in CI?
  - plorkyeran 2y ago
    I disabled SIP in our CI environment because with ~5 Xcodes installed and VM images that were reset to a baseline every day or two the malware scanning often literally didn't finish before the VM was reset and it was forced to start over, and while it was running builds took 2-3 times as long. I probably could have done something fancy where the VMs were left running a day or two before being frozen and deployed, but disabling SIP was the much simpler solution to the problem.