“eskimo”

I wanted to post a quick update here. The short answer is that we have no idea what’s going on )-: At my request, jmb2013 filed a bug about this (FB24177273) and one of the keychain engineers dug deep into the issue and came back with… nothing. Specifically, we captured a copy of jmb2013 keychain and everyone on our side of the fence is able to add that keychain to Keychain Access and see the certificate and private key pair up. However, that doesn’t work for jmb2013. We even went so far as to test this with an M4 Mac and the same OS release as jmb2013. And clearly this isn’t a super widespread problem or lots more folks would be reporting it. Mmmatiss, I’ll probably have more stuff for you tomorrow, but for the moment I wanted to ask for you to respond to this… jmb2013 wrote: Did you set up your M5 Macbook using a time machine backup from an older Mac? That’s one thing that we haven’t tested, and if you took that step as well then we should probably look into it. Share and Enjoy — Quinn “The Eskimo!

[quote='904028022, Bikrrr, /thread/823588?answerId=904028022#904028022, /profile/Bikrrr'] Is there a published list of things that can result in moderation? [/quote] Not specifically. In general the moderators enforce the rules published in Apple Developer > Support > Developer Forums and Apple Developer Forums Agreement. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for all that additional info. Most interesting. securityd is a bit like the kernel. You shouldn’t be able to crash it just by calling its API. Rather, if you make a mistake like this, securityd should start returning errors or, in extreme circumstances, kill you. Given that, this failure is automatically bugworthy, and I’d appreciate you filing a bug report about it, including a sysdiagnose log taken shortly after reproducing the problem. Please post your bug number, just for the record. Looking at the crash report I have some theories as to why it actually crashed, but I don’t want to go too far down that rabbit hole. Rather, I’d like to stay focused on what you’re doing. [quote='903875022, gilmatok, /thread/844097?answerId=903875022#903875022, /profile/gilmatok'] 1- Is our root cause plausible from your side? [/quote] It’s certainly plausible. Regardless, the current behaviour of your keychain code is clearly wrong, and thus you should fix that. [quote='903875022, gilmatok, /thread/844097?answerId=90

I presume by “FDA” you mean Full Disk Access. If so, I’m not sure how that relates to this. There’s clearly an FDA check in here, but I doubt that com.apple.vm.device-access will get around it. Do you have concrete evidence that com.apple.vm.device-access will actually help here? It’s been a while since I looked at the details of this, but: Everything that’s gated by com.apple.vm.device-access has a bypass for root. When something fails due to the absence of com.apple.vm.device-access, it fails with kIOReturnNotPrivileged, not the kIOReturnInternalError that you’re seeing. What is the full error you get back here? My experience is that IOUSBHost types are pretty good at populating the userInfo dictionary of the error with useful stuff. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK. What does this report? % pkgutil --check-signature /path/to/your.pkg Pasted in below is an example of what I see. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com % pkgutil --check-signature Test843122.pkg Package Test843122.pkg: Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-09-03 12:26:25 +0000 Certificate Chain: 1. Developer ID Installer: Quinn Quinn (SKMME9E2Y8) Expires: 2027-07-12 13:47:32 +0000 SHA256 Fingerprint: 15 4E 11 93 04 99 B2 15 4E 9B 1E AF 9E 2C 72 C7 BA 48 E1 8C 61 18 C9 0A E4 62 A3 EF 87 94 79 D4 ------------------------------------------------------------------------ 2. Developer ID Certification Authority Expires: 2031-09-17 00:00:00 +0000 SHA256 Fingerprint: F1 6C D3 C5 4C 7F 83 CE A4 BF 1A 3E 6A 08 19 C8 AA A8 E4 A1 52 8F D1 44 71 5F 35 06 43 D2 DF 3A ------------------------------------------------------------------------ 3. Apple

[quote='903947022, tttaaabbbccc, /thread/843331?answerId=903947022#903947022, /profile/tttaaabbbccc'] This is not the App crashing. [/quote] Understood. I was looking for the altool crash report. If you run the Console utility and select Crash Reports on the left, you should see it in the list. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Filed it here: FB14267090 Hmmm, that’s not right. FB14267090 is an Apple TV bug filed back in 2024. Can you recheck that number? ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='903891022, Mr. Jefferson, /thread/842766?answerId=903891022#903891022, /profile/Mr.+Jefferson'] I don't believe 1% of terminations works out to enough to explain the numbers of reports I've been seeing [/quote] Agreed. After posting my response yesterday I had a chat with DTS’s crash report experts [1] and they pointed me at this quote from the docs: The following crash report types aren’t available through the Crashes organizer … Watchdog events, such as those from slow app launch times Invalid code-signature crashes Thermal events, where a device overheats because an app uses too much CPU Jetsam events, where an app has high memory use While this list doesn’t specifically mention 0xdead10cc terminations, it seems that they fall into the same trap (r. 110550085)-: [quote='903891022, Mr. Jefferson, /thread/842766?answerId=903891022#903891022, /profile/Mr.+Jefferson'] If you mean that MetricKit on iOS 27 is better … [/quote] Right. This is what I see for a 0xdead10cc crash on iOS 27.0b8: { … crashDiagn

Hmmm, that sounds like a bug to me. Please file it as such, then post your bug number, just for the record. Make sure to include your test project and a sysdiagnose log taken shortly after seeing the issue. Coming back to your real app, are you sandboxing it because you’re targeting the Mac App Store? Or simply because it’s the right thing to do? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In my case, I’m confident it was moderated. You are correct. I can see what happened here, but I have no insight into why it happened. And this happened sufficiently long ago that I’m not able to investigate that further. Moreover, due to a limitation of the forums platform, I’m not able to restore content that was mistakenly removed (r. 144511093). If this happens again, please reply on this thread and I’ll take another look. IMPORTANT Make sure to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='844482021, thespian, /thread/844482, /profile/thespian'] Is it supported to consume packets … send them to the public Internet without a remote VPN endpoint [/quote] No. Packet tunnel providers are intended to be used for VPN and, by definition, that involves a VPN server. While it may be possible to do what you’re trying to do [1], DTS doesn’t support that. See TN3120 Expected use cases for Network Extension packet tunnel providers. Note This is a DTS policy. I don’t work for App Review and can’t comment on their policies. I suspect you’re on iOS, in which case your alternative options are limited. If you happen to be targeting macOS, you can do this sort of thing using a transparent proxy. TN3134 Network Extension provider deployment has more info about the distribution limitations for the various NE provider types. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I’ve seen deeply approaches used: Re-inject pac

[quote='903834022, KrishnaveniNalka, /thread/844416?answerId=903834022#903834022, /profile/KrishnaveniNalka'] Created FB24619068 [/quote] Thanks. That’s the best path for this. It’s generally true that your app should be able to trigger a system-wide hang! Looking at your bug I see there’s no sysdiagnose log. Please take one at the time of the hang and then add it to your bug. Even though you’re attached a test project — and thanks for that! — a sysdiagnose log is important to make sure your bug gets routed correctly. See our Bug Reporting > Profiles and Logs page for more about sysdiagnose logs. Oh, and if the standard key chord doesn’t work when the system is hung like this, you can SSH into the Mac and run the sysdiagnose command-line tool. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The behaviour you’ve described doesn’t surprise me. I’ve not looked into the Ethernet side of this, but what you’re seeing closely matches the Wi-Fi behaviour. That is: If you lock the screen, your app moves to the background and shortly thereafter gets suspended, meaning that it’s unable to perform networking. If the device sleeps, the system disassociates from Wi-Fi. I talk about these ideas in a lot more detail in the various posts linked to from Extra-ordinary Networking. [quote='903945022, Qinhan_Li, /thread/844516?answerId=903945022#903945022, /profile/Qinhan_Li'] Does this require MFi support … ? [/quote] AFAIK MFi doesn’t have any specific provisions for Ethernet. [quote='903945022, Qinhan_Li, /thread/844516?answerId=903945022#903945022, /profile/Qinhan_Li'] Does this … a specific iOS entitlement? [/quote] AFAIK there are no entitlements related to this. What’s the actual problem you’re trying to solve here? I suspect that you’re trying to communicate between your app and this Ethernet-based accessory

The iOS SDK has no APIs for getting precise CPU core temperatures. If your goal is to adjust your app’s behaviour based on the thermal state, there are APIs to help with that. The general-purpose API is ProcessInfo.thermalState (see here), but there may be more specific APIs provided by the subsystem you’re working with. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

While it’s true that we don’t support third-party tools in general, in this case I think you’ll find that the same issue affects Xcode-built apps. And, yeah, these URL schemes are something you’ll have to test on real hardware. The simulator is a great tool for day-to-day development, but it’s a simulator, not an emulator, and thus a lot of integration-y stuff just don’t work there. Oh, and btw, error -10814 is actually a public error code in the macOS SDK, namely kLSApplicationNotFoundErr. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com