“eskimo”

Let’s start with some terminology. On Apple platforms we typically use the terms app and application to refer to things with a GUI that the user launches from the Finder (on macOS), Home screen (on iOS), and so on. If you’re building a program that you expect the user to run in Terminal, that’s a command-line tool. Using the keychain from a command-line tool is a bit tricky because: We generally recommend that folks using the data protection keychain rather than the file-base keychain. Access to the data protection keychain is mediated by restricted entitlements, that is, entitlements that must be authorised by a provisioning profile. It’s hard to sign a command-line tool with such entitlements because there’s no obvious place to put said provisioning profile. Now, all of that is gonna sound like word salad if you’re new to the Mac, so lemme drop in some links: TN3127 Inside Code Signing: Requirements explains the different keychain implementations on macOS. TN3125 Inside Code Signing: Provisioning Profiles e

[quote='824253021, glendc, /thread/824253, /profile/glendc'] the ordering is not clear? [/quote] Indeed. The ordering is undefined unless the transparent proxies are deployed via MDM. In that case the device manager can specify an order using the Order property. Once you start mixing multiple types of Network Extension providers, you have to worry about the order between those types. I’m not aware of any documentation for that, but understanding is that it’s something like: per-app VPN, content filter, relays, transparent proxy, general VPN, and finally DNS proxy. When it comes to multi-provider compatibility, there’s one code-level step you can take: When making a connection on behalf of a flow, pass the flow metadata to the connection. See this post. In terms of compatibility with specific products, it’s hard offer concrete advice on that front: It’s not clear which products use which provider types. Some Mac products don’t use NE at all, but instead rely on legacy VPN techniques. There’s no guarantee that

Can you clarify what you mean by “production bundle identifier”? Most apps use a single bundle ID for both development and distribution. Are you doing something special to vary bundle ID in those two cases? ps The majority of weird ‘only shows up in production’ problems I see are caused by Debug vs Release build changes, rather than code signing changes. I talk about this more in Isolating Code Signing Problems from Build Problems. However, the process there assumes you’re using the same bundle ID in both cases, and if you’re not then… well… things get more complex. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885745022, glendc, /thread/824202?answerId=885745022#885745022, /profile/glendc'] is the system keychain the recommended place to store this? [/quote] That’s what I’d use, possibly with a scrambling layer to prevent casual extraction. [quote='885745022, glendc, /thread/824202?answerId=885745022#885745022, /profile/glendc'] [is it] possible for a system extension to use/own a private (persistent) key via the secure enclave? [/quote] This is trickier. First up, keys don’t exist in the Secure Enclave. Rather, they are protected by the Secure Enclave, that is, wrapped in a way so that only the SE can use them. The traditional way to get an SE-protected key is via the keychain API. See Protecting keys with the Secure Enclave. And as you’ve discovered in my other posts, that’s tied to the data protection keychain, so not available to your sysex. However, you can now work with SE-protected keys using Apple CryptoKit, and that changes this story. See this post for the full story. Elsewhere [1] you wrote: Can

[quote='824282021, DeviceManagementPM, /thread/824282, /profile/DeviceManagementPM'] want to highlight for others. [/quote] Cool. [quote='824282021, DeviceManagementPM, /thread/824282, /profile/DeviceManagementPM'] We've put in a feedback assistant request [/quote] What was that bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885785022, AmbritSoftware3, /thread/823398?answerId=885785022#885785022, /profile/AmbritSoftware3'] As for Mac I think I will forget that. It's yet another can of worms. [/quote] I don’t understand this comment. The Mac is the one platform where the rules for direct distribution are really clear. To pass Gatekeeper: You must sign your code with a Developer ID Application signing identity. If you distribute a disk image, you should sign it with the same. If you distribute an installer package, you must sign it with a Developer ID Installer signing identity. You must notarise your product. All of the above is available to all paid teams. Xcode can take care of the code signing side of this. If you’re not using Xcode, or you want to automate things, see Creating distribution-signed code for macOS. And for advice on the packaging, see Packaging Mac software for distribution. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.c

[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 HTTPS traffi

[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 deal with that by bookmarking the page with the sort criteria embedded. So, rather than this: https://developer.apple.com/forums/topics/developer-tools-and-services/developer-forums I bookmark this: https://developer.apple.com/forums/topics/developer-tools-and-services/developer-forums?sortBy=activity&sortOrder=desc I can then open the page and look for unread threads, which are easy to spot because the title is in bold. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885585022, chbeer, /thread/805681?answerId=885585022#885585022, /profile/chbeer'] It only crashes in release build without debugging [/quote] Well, that’s actually a good thing, in that: We suspect that this is an Apple problem, rather than a problem with your code. It’s pretty easy for Apple folks to install and test with the released version of your app, assuming it’s shipping on the App Store. So, can you reliably reproduce this with the App Store version of your app? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885705022, Frankois944, /thread/729371?answerId=885705022#885705022, /profile/Frankois944'] is it possible to force the UIRequiredDeviceCapabilities? [/quote] I believe that App Review has a way to allow this. However, before you reach out to them you should carefully think about this choice. By narrowing the set of supported devices, you’re prevent existing users of your app from updating to your latest version. You should carefully consider whether that’s worth it, especially when dealing with a very old app. It might be better to simply ship a new app. Or do what endecotp’s recommended above, that is, not make NFC a requirement. Or you could do both, that is, publish a new app that requires NFC and also update your old app such that the existing functionality, the stuff that you’re users have been using for years, continues to work on devices with NFC. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='885574022, rbmanian75, /thread/822658?answerId=885574022#885574022, /profile/rbmanian75'] i cant access the feedback you have mentioned [/quote] Indeed. One option is to file your own bug and asked that it be marked as a dup of FB7731708. If and when we start seeding an OS release with a fix for that bug, you’ll be notified via your bug. ps This is one of the many hints and tips you’ll find in my Bug Reporting: How and Why? post. 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

Hmmm, you’re implementing an authorisation plug-in. Have you spoken to me privately about that already? If not, please open a DTS code-level support request so we can have a quick conversation, after which I’ll come back to this thread. IMPORTANT When you submit the support request, the form asks if anyone from Apple asked you to submit in. Make sure you fill out that field, and reference my response on this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='824218021, siddhant-mac, /thread/824218, /profile/siddhant-mac'] From our side, these appear to be system-owned Platform SSO dialogs [/quote] Indeed. Given that, this sounds like a bug to me, and I encourage you to file it as such. 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