“eskimo”

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for additional 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 exact mechanism used by macOS to associate an app with its container is considered an implementation detail [1]. It has changed in the past and I wouldn’t be surprised if it changed again in the future. Beyond that, it’s hard to offer advice without knowing more about what you’re trying to do. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Such implementation details are sometimes documented in Apple Platform Security. I took a quick look and didn’t find anything, but you might have more luck than I did.

I read your post a few times and I’m not entirely sure what this is about. It sounds like you’re trying to look at the value of com.apple.quarantine and then draw conclusions from that. That’s not something we support. The on-disk structure of the com.apple.quarantine attribute is not considered API. There is API for interacting with a file’s quarantine state (start here) but that’s primarily there for folks who are actually trying to quarantine files [1]. Interpreting an arbitrary value you get back via that property is gonna be tricky, because the target ‘audience’ for this property is Gatekeeper, not other apps. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Or completely remove quarantine from files.

I’m glad you asked these questions because it gave me an opportunity to clarify my own understanding of this. There are some general principles here: If the filter provider isn’t available — for example, it crashed before the system could pass it the flow — the system will drop the flow. If the filter provider allows a flow and then crashes, that will have no effect on the flow. It’ll keep on… ah… um… flowing (-: If the system passes a flow to the filter provider and the filter provider crashes before it’s resolved the flow — so, no deny or allow verdict — then the system will drop the flow. It sounds like this matches what you were hoping for, so that’s good news. However, I suspect that this is a case where the combined behaviour of your product and the system is critical to the security guarantees of your product, and my standard advice is such cases is to add your own integration tests to ensure that you get the behaviour you want. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Suppo

Has anyone tried this on the latest beta seed? Currently that’s macOS 27.2b4 (26B5112a). I’m hoping you see some improvement (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='909696022, DTS Engineer, /thread/850631?answerId=909696022#909696022'] I think we might’ve fixed it already. [/quote] We have indeed, which is great. Alas, I have no info to share about when that’ll land externally. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='909808022, laoblin, /thread/851167?answerId=909808022#909808022, /profile/laoblin'] The immediate goal is a reliable native process-identity check within an automated test workflow. [/quote] OK. Who is checking whose identity here? Reading your second reply it sounds like you want Observer (the parent) to be checking Query (thi child). If so, you don’t need custom machinery for that. Rather, have Observer run Query with a launch requirement that ensures its identity. The easiest way to construct these requirements is with the LightweightCodeRequirements framework. Once you have one you can apply it using the launchRequirement property on Process. Annoyingly, the corresponding Posix spawn attribute is SPI )-: See here. If you’d like to stick with posix_spawn, I encourage you to file an enhancement request to make that API. And if you do that, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo

Ah, sorry, I should’ve been more clear. If you sign the parent app with the necessary microphone entitlements, does the child process you spawn inherit them? That is, do you see this correlation: parent signed with | VM managed by child microphone entitlements | can use microphone ----------------------- + ------------------- no | no yes | yes Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Well, regardless of the cause, that’s definitely bugworthy. 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

Hey hey, I made exactly the same mistake that you did! I’m glad one of us finally noticed, and thanks for cluing me in. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hmmm, weird. The reason I suggested sample is that it’s quick’n’easy. Other tools, like spindump and sysdiagnose, produce more useful output, but are take longer to do it, which is annoying for transient errors like this. If you’re going going to set up a long term test to looking for this, then sysdiagnose is the right option. It produces the most info. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='851713021, anonymoussingh, /thread/851713, /profile/anonymoussingh'] We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback. [/quote] If it’s annoying, it’s worth filing a bug about it. I like to think about it this way: Either it’s a bug. Or it’s working as designed, in which case you’re actually filing a bug against the design. If you do file a bug about this, it’d help if you included a minimal test project that illustrated the issue. One good option here is to try reproducing it with QAuthPlugins. If it reproduces directly, you can include that. If not, apply your tweaks until it does. Oh, and also make sure to include a sysdiagnose log taken shortly after reproducing the issue. Oh, and if you can get a screen recording, that’d be grand. Historically you could do this by SSHing into the affected machine and recording the screen using the screencapture tool. I think that still works but, if not, you can always record the screen using your iPhone. When you’re done, pl

I’m not sure if you’ve seen the Validating Signature Of XPC Process thread but, if not, there’s a link to it in XPC Resources. I recommend that you read that first and then come back here with your follow-up questions. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not sure what you mean by “console” in this context. When managing an app there are four things you might use: App Store Connect — This has a whole bunch of functionality — see App Store Connect Help — but it doesn’t let you upload builds. Xcode — If you’re building your app with Xcode, you can upload it using the Xcode organiser. altool — This is a a command-line tool for uploading apps and more. Transporter — This is a GUI app for uploading apps. You can find more info about the last three items in App Store Connect Help > Manage builds > Upload builds. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Well, that was interesting. I did a bunch of research on this topic yesterday, and the conclusion was that there isn’t a way to stop a malicious client sending you a message that runs you out of memory O-: One way around this is to create an XPC service that acts as a proxy to your main service. The XPC service checks the validity of incoming messages before passing them along to your main service. And the main service uses a peer requirement to ensure that it only accepts messages from the XPC service. The mechanics of how you’d apply this approach is gonna depend on your packaging. Is your named XPC endpoint run by an XPC service or a launchd daemon or agent? And if it’s the second case, is it invoked solely by apps that you create? Or do you expect it to be invoked by other third-party code? Oh, and we’d welcome an enhancement request for a way to limit the message size. It’s not clear exactly what’s feasible in this space, but feel free to put your own requirements into the bug and the XPC team can consid