“show when run”

Part 1... Disclaimer: Some of the information here may already be obvious or well understood to you. If it is, then thank you for your patience as I use this as an excuse to push out background information that other developers may find useful. Oh, I think I was a little unclear in what I wrote. What I was trying to say in a call to enumerateDirectory of this nature was that if I call enumerateDirectory with a non-minimal attribute set (i.e. include attributes that need more I/O to fetch), then I see that behavior. But you're right in that iterating over a directory with minimal attributes doesn't generally have additional lookupItem calls in my tests. Again, you have to be careful of the API you're using. The classic Unix directory iteration pattern[1] is to read the directory (readdir-> enumerateDirectory) and then retrieve metadata (stat-> lookupItemNamed). There are two problems with that: At a basic level, it generates a lot of syscalls, each of which nibble away at performance. From the file syste

It turns out we were not able to reproduce the crash with the following steps: Downloaded and installed their attached test app onto both paired iPhone + Apple Watch. Allowed data type authorization requested by the app. On watch launch, background observer query should have started as they implemented in applicationDidFinishLaunching. Could see the HR samples being retrieved by the query in the app’s UI when new data was detected. Put app into background, waited some time, injected new sample. Waited an hour+, injected new sample. Repeated the waiting+sample injection a few times. RE-foregrounded app. Used their refresh UI button. Could see the new samples showing up in UI. In this whole process, we never experienced an app crash or noticed a “CSLHandleBackgroundHealthKitQueryAction watchdog transgression” log on the watch (had a stream open the entire time). For us to further investigate the issue, would you mind to: Provide more granular specific reproduction steps about how to reproduce the crash

[quote='885695022, MasterYourSelf, /thread/823729?answerId=885695022#885695022, /profile/MasterYourSelf'] I’m referring to a MITM proxy in the generic sense [/quote] OK, cool. mitmproxy is super cool, but running that code in a system extension would present some challenges. With that out of the way, let’s return to your original questions: [quote='823729021, MasterYourSelf, /thread/823729, /profile/MasterYourSelf'] 1- Is it a good idea to implement TLS inspection within a system extension … ? [/quote] Yes and no. TLS inspection itself has significant drawbacks, so it’s hard to say that it’s a good idea overall. But if you’re going to implement it then using an NE transparent proxy is a reasonable way to do it. Transparent proxies do have their sharp edges, but the only alternative is to use a traditional proxy and that requires cooperation from the apps involved [1]. [quote='823729021, MasterYourSelf, /thread/823729, /profile/MasterYourSelf'] 2- As NETransparentProxyProvider already intercepting HTT

Thank you very much Quinn! That clarifies a lot... Using the system keychain is for sure the easiest path... The cryptographic secret I am trying to protect is in this case a local CA private key for developer security products to block malware etc... I suppose it shouldn't matter that the root user can access it as the CA is isolated and specific to that device, so not like there's a security risk there and I suppose if you have an attacker with root access that is not the user, I suppose you anyway have bigger issues than this... Also thank you for correcting me with the terminology.. So to recap? For a system extension, that has such a secret specific and only used by that extension (e.g. the ca private key), is the system keychain the recommended place to store this? Also a second question. I was trying to use the secure enclave to get a private key so that i can perhaps encrypt/decrypt data stored in the system extension app container but also here I was running into errors... Can you clarify Qu

[quote='885561022, Pavel, /thread/823101?answerId=885561022#885561022, /profile/Pavel'] there is no other options without an MDM? [/quote] That’s not quite the point I’m trying to get across here. In my experience there are two happy paths: Have the user do everything from the container app’s GUI. Have the device manager do everything via MDM. I recommend that you build your product to support those paths. So, for a user who’s Mac isn’t managed, they should install your product using the GUI. My experience is that: There are lots of folks who don’t like that advice. And thus create an installer the ‘simplifies’ the installation process in the non-MDM case. Which tends to run into weird problems, either in specific environments or as the system evolves. So, you do have a third option here, it’s just that I have good reasons to not recommend it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I want to clarify a few points from both your original post and Albert’s response. You’re using the term keyring, which is not a thing on Apple platforms. Rather, the equivalent thing is called the keychain. Using the right term will help, for example, when you go searching for documentation. macOS has two keychain implementations: The file-based keychain The data protection keychain We generally recommend the data protection keychain. However, you’re building a Network Extension transparent proxy, and those are generally packaged as a system extension [1]. Sysexen are roughly equivalent to a launchd daemon, and cannot use the data protection keychain. They can only use a file-based keychain, typically the System keychain. TN3137 On Mac keychain APIs and implementations talks about this stuff in much more detail. When talking about extensions on Apple platforms, it’s important to get your terminology straight. The application in which the extension is embedded is called the container application. The host app

As a software developer, my daily workflow involves running large numbers of terminal sessions simultaneously (tmux, multi-project workspaces, automation scripts, node-pty connections, etc.). The default PTY limit of 511 is far too low for modern development workflows. Furthermore, this default value is identical across all hardware — a maxed-out Mac Pro with 128GB RAM has the same 511 limit as a base-model MacBook Air, which doesn't scale with hardware capabilities. I've tried tmux control mode to reduce PTY usage, but it causes terminal output alignment issues that make it impractical for daily use. This means I must use PTY mode, and hitting the 511 ceiling is a frequent occurrence. Once the limit is reached, no new terminals can be created system-wide — not just in my app, but across Terminal.app, iTerm2, VS Code, and any other terminal-dependent process. This becomes a system-wide stability issue. Summary: 511 is an outdated default for modern developer workflows No hardware-aware scaling — same