“eskimo”

Well, that’s exciting. First up, let’s get Flutter out of the mix. Try this: Use Xcode to create a new test project, giving it the same bundle ID as your real app. Do a Product > Archive. In the Xcode organiser, export the .ipa from that archive. Re-run your codesign test. Does it have the same problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='902580022, zeeqeeng, /thread/842864?answerId=902580022#902580022, /profile/zeeqeeng'] do they live in memory since boot just like kernel XNU too? [/quote] No. The dynamic linker shared cache is actually a giant file with all the system share libraries glommed together. This isn’t all held in memory, but rather the contents of that file gets mapped into processes are necessary. There’s a bunch of complexity involved. I’m not going to go deeper into this because these are all implementation details and have changed over the time. But on current versions of macOS you should feel free to rummage around in /System/Cryptexes/OS/System/Library/dyld/. WARNING This stuff has changed in the past and I fully expect it to change in the future. Don’t encode knowledge about these implementation details into a shipping product. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for sharing. I’ve made sure that the folks looking at FB24377808 are up-to-speed on this. And with that, I’m gonna step out of this particular loop. If and when things change, I expect you’ll hear about it via FB24377808. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for those. Both crashes show that the main thread crashed with a backtrace like this: 0 libsystem_kernel.dylib 0x24929dcd4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x2492a130c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x2492a122c mach_msg2 + 4 3 libsystem_kernel.dylib 0x2492a122c mach_msg_overwrite + 424 4 libsystem_kernel.dylib 0x2492a1078 mach_msg + 24 5 CoreFoundation 0x1998cc344 __CFRunLoopServiceMachPort + 160 6 CoreFoundation 0x199896310 __CFRunLoopRun + 1188 7 CoreFoundation 0x19989554c _CFRunLoopRunSpecificWithOptions + 532 8 GraphicsServices 0x23f87d498 GSEventRunModal + 120 9 UIKitCore 0x19f5c9670 -[UIApplication _run] + 796 10 UIKitCore 0x19f534158 UIApplicationMain + 332 11 BRFree 0x1028d5b78 12 dyld 0x1964a1c1c start + 6928 This is pretty standard for crashes that aren’t really crashes, for example, when your app is terminated by the watchdog. In most such cases MetricKit captures relevant info in the terminationReason field, but that hasn’t happened here )-: I’m still researchin

[quote='903236022, Ray-87, /thread/842911?answerId=903236022#903236022, /profile/Ray-87'] they are independent checkboxes [/quote] Yeah, that’s a trick one. [quote='903236022, Ray-87, /thread/842911?answerId=903236022#903236022, /profile/Ray-87'] an Apple DTS engineer describes this exact one-of-two trap in thread 835229 [/quote] Hey, that’d be me (-: For the benefit of those following at home, here’s a link to my reply. It has screenshots! (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Since multiple unrelated apps/services are affected, it seems unlikely our app triggered it. Agreed. But not impossible. If you were, for example, developing an endpoint security product then it’s possible that this is being triggered by that. Could macOS 26.6.x have changed how access to the login keychain is handled? Well, as I mentioned above, macOS 26.4 kicked off a process for changing how the system handles the file-based keychain, and so this is definitely a possibility. Are you able to reproduce this on a ‘clean’ install, that is, one that’s never had your software installed? Oh, and earlier you wrote: [quote='844097021, gilmatok, /thread/844097, /profile/gilmatok'] Apple Support observed a securityd crash followed by [/quote] Did you capture the resulting crash report? If so, please post it here. See Posting a Crash Report for advice on how to do that. Or, if it went into a bug then please post the bug number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let my

Thanks for the update. I’ve passed that along to the relevant folks. Unfortunately, I don’t have any timeline for a resolution here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='902995022, dverevkin, /thread/842811?answerId=902995022#902995022, /profile/dverevkin'] I’ve found that code signature verification fails with an ELOOP [/quote] Yowsers! As I said on anonymoussingh’s thread, it’s hard to imagine this being anything other than a bug. Thanks for updating your bug report (FB24415432) with your latest findings. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844283021, anonymoussingh, /thread/844283, /profile/anonymoussingh'] ELOOP, too many levels of symbolic links [/quote] Hmmmm, it’s hard to imagine that being anything other than a bug. Thanks for filing FB24601496 about it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

iOS has full support for USB Ethernet. If you attach such an accessory, and the Ethernet is connected to the wider Internet, iOS will bring up TCP/IP on that interfaces and set it as the default route. Apps have access to this interface in the same way they have access to Wi-Fi. Things get more complicated when your Ethernet does not lead to the wider Internet, which is typically what happens when you try to use this for accessory integration. iOS will still add the interface to TCP/IP but it won’t become the default route. Apps can access such interfaces, but there are restrictions. I have a lot of background to this stuff in the various posts linked to by Extra-ordinary Networking. Specifically, heed the high-level guidance in Working with a Wi-Fi Accessory, that is, support IPv6 and Bonjour. My advice is that you prototype this with an off-the-shelve USB Ethernet device. Connect the Ethernet side of that to a switch and hence to a computer that emulates your accessory. You can then see create a prototype i

[quote='844177021, hahuja, /thread/844177, /profile/hahuja'] NEPacketTunnelProvider … modifies DNS responses for specific hostnames as part of its normal operation. [/quote] To what end? Most folks who run into problems like this do so because they’re trying to use a packet tunnel provider for something that isn’t VPN. That’s not something we support, for the sorts of reasons you’re seeing here. See TN3120 Expected use cases for Network Extension packet tunnel providers. [quote='844177021, hahuja, /thread/844177, /profile/hahuja'] Would a NEDNSProxyProvider-based DNS proxy be affected in the same way … ? [/quote] I don’t know for sure, but I’d be surprised if that were relevant to you because most folks in this situation are using a packet tunnel provider because they don’t want to accept the deployment restrictions imposed by DNS proxy. See TN3134 Network Extension provider deployment. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ +

The forums is primarily focused on Apple APIs, and AFAIK there’s no API that will help with this. Rather, it’s an on-the-‘wire’ Wi-Fi issue. The best way to report that is via Feedback Assistant [1]. See Bug Reporting: How and Why? for general advice on that and Filing a Wi-Fi Bug Report for Wi-Fi specific stuff. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Which isn’t to say that this is a bug on our side. It’s possible that there’s a Wi-Fi option you can tweak at your end. I just don’t have enough expertise in that level of Wi-Fi to say anything definitive here.

Thanks for filing FB24553094. [quote='843971021, norsegaud, /thread/843971, /profile/norsegaud'] unless of course there is a great reason not too. [/quote] I don’t think there’s any specific reason why we wouldn’t fix this, but I can’t offer any specific timeline. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My understanding is that there are two levels of PIR approval: The Approved state indicates that your request has been approved but isn’t yet configured. The Successfully Onboarded state indicates that everything is ready to go. Please check the state of PIR requests. If they’re in the first state then the behaviour you’re seeing makes sense. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844209021, Registered_User, /thread/844209, /profile/Registered_User'] Also filed via Feedback Assistant. [/quote] That’s the correct path for this. What was your bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com