“eskimo”

The other way to slice this would be for Apple to relax the Personal Team provisioning limitations on the Mac [1]. I’m pretty sure I’ve discussed that idea before on the forums, but I wasn’t able to track down the link. Anyway, OC_s, if you’d like to see Apple change its Personal Team policy for macOS, I encourage you to file an enhancement request along those lines And 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 [1] For more about those limitations, see Developer > Support > Choosing a Membership.

[quote='849259021, Auxentis, /thread/849259, /profile/Auxentis'] I have read that first submissions may be held for in-depth analysis … [/quote] Right. That’s very likely to be the case here. I’ve included a copy of my standard spiel about this below. Given that I missed your post last Friday, I suspect that this has cleared already. If it’s not cleared by Wednesday, please reply back here and I’ll dig deeper. 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 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.

[quote='849418021, sv-vm-dev, /thread/849418, /profile/sv-vm-dev'] DRAFT, NOT SENT [/quote] What does you mean by this? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Swift Playground has a extras (…) menu and on that menu there’s an Advanced > Sign Out item. If you choose that and then choose Advanced > Sign In, does that clear the issue? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I was able to reproduce this from a clean macOS 26.6 VM: % sw_vers ProductName: macOS ProductVersion: 26.6 BuildVersion: 25G72 % xcode-select --install … % cat hello.c #include int main(int argc, char ** argv) { printf(Hello Cruel World!n); return 0; } % clang hello.c ld: tapi error: malformed file /Library/Developer/CommandLineTools/SDKs/MacOSX27.0.sdk/usr/lib/libSystem.B.tbd:4:20: error: unknown architecture arm64e.x1-macos, arm64e.x1-maccatalyst ] ^~~~~~~~~~~~~~~ … The thing to note here is that tapi is coming from the command-line tools package: % xcrun -f tapi /Library/Developer/CommandLineTools/usr/bin/tapi so it should be able to handle the .tbd file within the macOS 27 SDK. I’ll come back to that point below. Note If you’re not familiar with .tbd files, I have a quick intro in An Apple Library Primer. I encourage you to file a bug about this. And please post your bug number, just for the record. The easiest way around this is to install Xcode 27.0 and select its command-line tools: % sudo xcode-selec

What’s your high-level goal here? The Apple PKI page has links to various CA policy docs, but those are only part of the picture. Apple operating systems have various other mechanisms to prevent code from running, so you’re unlikely to get a meaningful signal via the certificate revocation path. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907594022, Brian_Rucker, /thread/849029?answerId=907594022#907594022, /profile/Brian_Rucker'] would you recommend anchoring this primarily to the lifetime and identity of the sender process … ? [/quote] Yes. Processes have commonly accepted semantics, but that’s not really true for security sessions. They’re more of an implementation detail than an API. And the primary API they’re used by, BSM, has itself been deprecated (check out the __AUDIT_API_DEPRECATED macro). My general take on this is to try to use audit tokens as much as possible, because they have built-in protection against pid reuse. You can see this via audit_token_to_pidversion, but I try to avoid relying on that but instead try to stick with APIs that work in terms of audit tokens [1]. For example, when dealing with code signing I prefer kSecGuestAttributeAudit over kSecGuestAttributePid. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] And sometim

[quote='907584022, marucello, /thread/849002?answerId=907584022#907584022, /profile/marucello'] This seems to indicate that … the failure is specific to the code-signing validation state on the host Mac. [/quote] Yep. Do you have any third-party security products installed on your main Mac? When I’ve see problems kinda like this in the past I’ve found that the developer was working in a managed environment, and their organisation’s endpoint security product had some unexpected side effects. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907586022, OC_s, /thread/848903?answerId=907586022#907586022, /profile/OC_s'] Found it meantime in System Information [/quote] Yep. My favourite trick is: % system_profiler SPHardwareDataType … Hardware: Hardware Overview: … Provisioning UDID: 00006034-001401301E88001C … [quote='907586022, OC_s, /thread/848903?answerId=907586022#907586022, /profile/OC_s'] HomeKit is a must in case of this particular app [/quote] Yeah, that makes things tricky. This is a Mac, so there are always options [1], but none of them are particularly good options. One thing that’d probably work is to set up Xcode on the other machine and use it to create a provisioning profile for that machine. You could then swap in that profile, and re-sign, as you bring the app to the other Mac. However, that’s not exactly easy, and you might run into other problems (I’m specifically concerned about Xcode invalidating the certificate in your original signing identity when you create a new signing identity on the new Mac). Share and Enjoy — Q

Did you file a bug about this? If so, what was that bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t have any info to share beyond what you can see in Feedback Assistant: The bug remains unresolved. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The discrepancy between the man page and the runtime behaviour is most is most definitely a bug — one or the other needs to change here — and I recommend that you file it as such. Your second issue also seems like a bug to me, especially given that it’s a change from earlier system. It’d be best for you to file a separate bug report about that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Yep, definitely a deliberate change (r. 174844817). [quote='849180021, jaikiran, /thread/849180, /profile/jaikiran'] Should the documentation … mention the acceptable value range for them? [/quote] Should questions are a hard for me to answer (-: so my response is gonna be: If you think that should be the case, I encourage you to file a bug against that man page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Indeed. This is a known bug in the forums platform (r. 136655649)-: The easiest workaround is to upload your content to a file sharing service (GitHub Gists are popular for this) and then post the URL. Note If you have problems posting the URL, see tip 14 in Quinn’s Top Ten DevForums Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com