Seth Willits (in 2022):
The new “ips” crash reports in macOS do not contain assert() information!
(Assertion failed: (myVar != nil), function fooBarTest(), file code.m, line 100)
Problematic because symbolication is often finicky, so it takes a LOT more work to find which assert() failed.
[…]
I don’t know whether it’s the “log” that’s to blame or that the ___crashreporter_info__ symbol is no longer supported, but even manually writing to it doesn’t show up in the log anymore.
I’m seeing this problem, too. My extra crash log information is not showing up on macOS 12.4 through 14.1 beta. It did work with previous versions of Monterey.
Dan Raviv:
I’m seeing the same issue. __crashreporter_info__ apparently still not working on macOS 13.6.
Previously:
Update (2023-11-22): Slava Egorov (via Saagar Jha):
Yeah, it’s really mysterious. I even stepped through it instruction by instruction. There is nothing too magical about it - it just stores string pointer into a special struct in section __DATA.__crash_info. But only the default value seems to reach crash dump.
My current theory is that it gets filtered somewhere (maybe for privacy reasons or security?). But have no idea how to debug that given that I can’t attach myself to whatever daemon that writes these logs. And I doubt it’s open source either.
Saagar Jha:
-[OSACrashReport _regionAtAddress:immutableCheck:] checks if the string is coming from an “immutable region” and if not will shunt the message into a “sensitive” version of the application specific info that is only logged on Apple Internal builds
The check appears to be (does the page not have VM_PROT_WRITE && is the address from the shared cache). abort_report_np will never work because it always copies its string (it does a sprintf). CRSetCrashLogMessage *can* work but you need to hand it something ReportCrash likes
Crash Reporter Debugging Mac macOS 12 Monterey macOS 13 Ventura macOS 14 Sonoma Programming
Malcolm Owen (Hacker News):
Mark Gurman claims that Apple has a system that can update the operating system of iPhones before they get sold. Crucially, it can do so without opening the box.
Consisting of a “pad-like device,” store employees place unopened iPhone boxes onto it to trigger an update. The pad wirelessly turns on the iPhone, runs the software update, then turns it off again.
This sounds convenient, though hopefully they’ve designed it so that it can’t be used after an iPhone has been set up.
Update (2023-11-22): See also: Accidental Tech Podcast.
Apple Retail Stores iOS iOS 17 iPhone MagSafe Software Update
Andrew Cunningham:
The look of the macOS login screen has been tweaked a bunch over the years, but it hasn’t been substantially rearranged since Lion (version 10.7) in 2011. Sonoma rejiggers things, moving the login field to the bottom of the screen, adding a big clock, and using the last logged-in user’s desktop wallpaper and/or screen saver as its background rather than the operating system’s default background image.
John Voorhees:
More impressive, though, is the large collection of aerial screen savers and wallpapers that are reminiscent of the Apple TV’s screen savers.
[…]
When your screen locks and the screen saver kick in, each high-resolution, slow-motion video begins. When you log back into your Mac, the screen saver continues for a couple of seconds more, creating a nice transition as your Mac wakes up. Each screen saver can be set as both a wallpaper and screen saver, or you can pick a screen saver that’s different from your wallpaper, although that isn’t currently working for me.
I like the aerial screen savers, and the default Sonoma Horizon looks good. However, they make it almost impossible for me to unlock my Mac via Screen Sharing. The animation of the desktop background behind the login controls is choppy, as expected. What I didn’t expect is that somehow this makes it lose most of the keystrokes for my login password. So I’ve changed to static desktop pictures on the Macs that I use with Screen Sharing.
Previously:
Lock Screen Mac macOS 14 Sonoma Screen Sharing Screensaver Wallpaper
Quinn:
The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance.
This post explains the fundamental underpinnings of the keychain.
[…]
A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class.
[…]
The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result.
Quinn:
If the keychain contains a generic password whose service (kSecAttrService) and account (kSecAttrAccount) attributes match those supplied but who’s generic (kSecAttrGeneric) attribute does not, the SecItemCopyMatching calls will return errSecItemNotFound. However, for a generic password item, of the attributes shown here, only the service and account attributes are included in the uniqueness constraint. If you try to add an item where those attributes match an existing item, the add will fail with errSecDuplicateItem even though the value of the generic attribute is different.
[…]
I regularly see folks use attributes that aren’t supported by the class they’re working with. For example, the kSecAttrApplicationTag attribute is only supported for key items (kSecClassKey). Using it with a certificate item (kSecClassCertificate) will cause, at best, a runtime error and, at worst, mysterious bugs.
[…]
A digital identity is the combination of a certificate and the private key that matches the public key within that certificate. The SecItem API has a digital identity keychain item class, namely kSecClassIdentity. However, the keychain does not store digital identities. When you add a digital identity to the keychain, the system stores its components, the certificate and the private key, separately, using kSecClassCertificate and kSecClassKey respectively.
Previously:
Keychain Mac macOS 14 Sonoma Programming
