eskimo

Honestly, I’m not sure what’s going on here. [quote='872215022, oleksandr91, /thread/810880?answerId=872215022#872215022, /profile/oleksandr91'] The mechanism is registered as non-privileged in both cases. [/quote] Hey hey, that was the next thing I was gonna ask you (-: OK, one more thing. Is the mechanism hosted by the same process in each case? I’d expect that to be the case, and for that process to be SecurityAgentHelper-arm64.xpc, but I wanna double check. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='872409022, KayleeSC, /thread/791352?answerId=872409022#872409022, /profile/KayleeSC'] I’d assumed they’d tell me something if I was approved [/quote] Indeed. We’re still working out the kinks in this process. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK, so definitely not your project. If you temporarily remove the iCloud key-value storage capability capability, the app builds, right? If so, look in the build log for an entry like this: CodeSign …/Test811382.app (in target 'Test811382' from project 'Test811382') cd …/Test811382 Signing Identity: Apple Development: Quinn Quinn (7XFU7D52S4) Provisioning Profile: iOS Team Provisioning Profile: com.example.apple-samplecode.Test811382 (5db3ba83-07fb-4780-8ca4-f87de64fd20d) Note For info on how to get the build log, see Command [something] failed with a nonzero exit code. The UUID in that entry is the UUID of the provisioning profile that Xcode is using to sign your app. You should find that in ~/Library/Developer/Xcode/UserData/Provisioning Profiles. Now dump the contents of that profile like so: % security cms -D -i 5db3ba83-07fb-4780-8ca4-f87de64fd20d.mobileprovision | plutil -p - { … Entitlements => { application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test811382 com.apple.developer.iclo

[quote='872309022, BigBalli, /thread/812679?answerId=872309022#872309022, /profile/BigBalli'] WKWebView operates independently with its own networking stack. [/quote] While it’s true that WKWebView does its networking out of process, it tries to hide that as much as possible by ascribing the networking to your app. For example, any cellular data consumed by WKWebView is ‘billed’ to your app. So, it’s not unreasonable to expect it to honour the Network framework default privacy context. 双木木, if you’re not seeing WKWebView honour the default privacy context and you’d like to see that change, I encourage you to file a bug about it. And if you do file a bug, 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

Is this correlated to an observable problem in your app? If not, see my advice in On Log Noise. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] it appears to contain 19 certificates [/quote] I agree that that’s strange. A distribution profile should only contain distribution certificates, and most teams only have one or two of those active at any one time. I recommend that you check the type of the profile and also look at the certificates embedded in the profile. [quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] Is there a way to find out which certificate is missing exactly? [/quote] Yes. TN3125 Inside Code Signing: Provisioning Profiles explains how you can pull apart the profile to work out what it authorises. You combine that with the --extract-certificates option to codesign, which allows you to determine the certificate of the code-signing identity that was used to sign the code. I’ve got some info on how to do that somewhere… Oh, right, here it is… Have a look at the Check the Signing Certificate section of Resolving Code Signing Crashes on Launch. Its foc

You can’t change the expiry date of a certificate. A certificates is signed by the issuer, and changing it would break the seal on its signature. Rather, you create a new certificate. Ideally you’d do this using the same public/private key pair that you used for the original certificate, so that the public key in the certificate doesn’t change. That means you’re not creating a new private key, which simplifies your workflows. If you’re doing this with the Developer website, use the same CSR you used when you created the certificate in the first place. Note that your provisioning profile embeds a reference to your signing certificate, so creating a new certificate will also require you to regenerate the profile. I have a lot of background info about this stuff in: TN3161 Inside Code Signing: Certificates TN3125 Inside Code Signing: Provisioning Profiles Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are two options available to third-party developers here: Sandboxed app containers — These are protected as of macOS 14. App group containers — These are protected as of macOS 15. I have links to the WWDC sessions that introduce these protections in Trusted Execution Resources. Neither of these is as tightly locked down as you’d like, but such is the nature of security trade-offs. And many of the MAC protected directories for Apple products, like ~/Library/Mail, have similar trade-offs, with ways around the protection like Full Disk Access or the Finder. And this is the Mac, so if the user turns off SIP then all bets are off. IMPORTANT If you do anything with app groups on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. [quote='872297022, SpacedCowboy, /thread/812688?answerId=872297022#872297022, /profile/SpacedCowboy'] where do you keep the master encryption key [/quote] My standard answer to that is the data protection keychain. That’s protected by the Mac’s code signing infrastructure

[quote='812733021, sschmitt_sq, /thread/812733, /profile/sschmitt_sq'] I'm working on an app that stores multiple secrets in the Keychain [/quote] What keychain item class are these? kSecClassGenericPassword? kSecClassKey? Or perhaps a mix? I’m asking because of the context discussed here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='812841021, fexlet, /thread/812841, /profile/fexlet'] I'm concerned about Apple's requirement that the endpoint … must not use self-signed SSL certificates. [/quote] You’ve misunderstood Apple’s position here. I suspect you’ve read about App Transport Security and assumed that its additional security requirement are enforced everywhere. That’s not the case. Rather: ATS is only enforced in specific situations. Even when it is enforced, there are ways to opt out of it. Some of those opt-out mechanisms involve providing a justification to App Review. In my experience, App Review applies a light hand here, accepting any reasonable justification. Some opt-out mechanisms don’t even require that, most notably NSAllowsLocalNetworking. IMPORTANT I don’t work for App Review and thus can’t make definitive statements about their policy. So the above comments are based on my experience working through issues like this with other developers. [quote='812841021, fexlet, /thread/812841, /profile/fexlet'] Is there a rec

Thanks for the clarification. I’ve updated your bug (FB20753534) with these details. Beyond that, there’s no much I can do for you. The correct path for this is Feedback Assistant, and you’re already on that path. I can confirm that your bug is being looked at by the right folks, and they’ll need to make a call as to how to address it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The Team is not yet configured for notarization error isn’t something we can help you with here on the forums. Like the error says, you have to contact Apple Developer Programs Support. For more on that, see this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='812847021, SimonCHendry, /thread/812847, /profile/SimonCHendry'] My understanding is that macOS ships BSD date [/quote] That’s generally a good way to approach issues like this, but in this case it seems that Apple has specifically added support for %N in recent OS releases, and documented it in date man page. AFAICT this landed in macOS 15. Certainly, it doesn’t work in 14.8.3 and does work in 15.6, which are the VMs I have handy. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Again, I’ll respond on the other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com