On macOS 15.7.1 I'm trying to install an XPC service outside the app (Developer ID). It mostly seems to go ok, but when I set Launch Constraints on Responsible, AMFI complains of a violation, saying the service is responsible for itself, and fails to launch. Removing that constraint (or adding the service itself to the constraint) works fine. The service is an optional download, and installed to /Users/Shared with a LaunchAgent specifying the MachService. The service is correctly launched and seems to pass all codesigning, notarization, and other checks, but the Responsible isn't set to the "calling" app. Is this broken, or working as intended?

What's the best/correct/current way of checking if a SecKey (or any keychain item) is allowed to be accessed (decrypted) by the current process? This would apply to signing or decrypting for a private key, or the data/contents of a password item (or key). Given the number of APIs deprecated, and that some of the listed interaction mechanisms don't seem to work (FB11153260), I was wondering if there was some SecItemCopyMatching magic, or something related to LAContext. In this use-case the SecKey is provided to this code, or it may fall back to enumeration by hostname (common name), so a persistent reference doesn't apply (though I realize that's a best practice). It looks like kSecUseAuthenticationUI doesn't work, and neither does kSecUseAuthenticationContext with interactionNotAllowed set to false. The deprecated SecKeychainSetUserInteractionAllowed still works though. In the past it was possible to enumerate the ACLs of an item using SecKeychainItemCopyAccess, but there doesn't seem to be an alternative. I was hoping it was possible to use kSecUseItemList with one of the kSecUseAuthentication* options in SecItemCopyMatching to return an error or an empty list, but that doesn't seem to work. Same with kSecMatchItemList. LAContext itself has a way to evaluate operations, but not with reference to a particular item. Either examination of the item (e.g. ACLs), evaluation of a policy (can sign?), or failure from something like SecItemCopyMatching would be fine, but it must work with interaction suppressed.

When creating a framer which will mark ready, we can't seem to get a reply to the first outgoing message sent by the framer, e.g. of the style: < 220 Service ready for new user.\r\n > AUTH TLS\r\n < 234 Command AUTH okay; starting TLS connection.\r\n The incoming message starting 234 is never received by the framer unless it marks ready right after sending the AUTH line. It looks like this is intentional but we can't understand why this is prevented given the framer should probably check the reply before attempting to prepend e.g. a TLS protocol on the stack (may depend on return code). The dependency seems to be that marking ready will allow the next read, but prevent prepending, and prepending will immediately trigger the TLS handshake, and it will consume the 234 line. It looks like "pass through" can be called any time, before or after, but that requires another protocol on the stack to do the work. Do we need to have one framer read the first message and send one message then mark ready and pass through, prepend another identical framer to read the next message then make the decision to prepend TLS, then prepend again for the "decrypted" framer to read the actual application protocol? We're doing this in C/ObjC, but I figured the Swift terminology might help in the title. Apologies if this was already asked somewhere, I couldn't find a good match.

We've recently noticed an issue on our new MacStudios where calls to psort_r(3) stall forever. We haven't changed our HPC (particle simulation) code at all, and sampling the app shows psort_r is stuck in dispatch_group_wait(3). Taking the code from Libc 1439.141.1, we've assembled our own implementation which allows us to pass a dispatch_queue_t, dispatch_group_t, and specify a wait time. After 10 seconds (a very long time in our case) the call returns with a non-zero exit code and shows the group and queue are in agreement: four additional blocks are waiting to dispatch, but haven't. This still takes more than two hours of simulation to achieve, where calls to psort_r must be succeeding to make forward progress. Prior to this code change we've seen dispatch_group_wait stuck for hours. What else could we do to diagnose/debug this? We only see it on our M1 Ultra MacStudios, and the comparator passed to psort_r is simple C code (constant time). FB10893202

Is there a simple way to create an NSFontCollection based on NSFontDescriptor querying to gather all installed/available fonts with a MATH table? It doesn't look like there's an attribute for that, but I don't know how else to search other than correlating with features like ssty, dtls, and flac.

Looks like dnsextd(8) was removed from macOS in 10.15 Catalina, and building from source isn't easy. I used the attached patch to build mDNSResponder 1310.140.1, which removes unused functions except for setTrafficClass which is unused by the target (it passes mDNSFalse for useBackgroundTraffic). We're planning to use this as a frontend to BIND 9.18.3 with an external daemon to verify TSIG for dynamic updates. With MDM we should be able to easily provision new TSIG keys remotely on servers, then communicate them out-of-band to the daemon and (hopefully) have the process work almost automatically. I have heard only RC4 is supported in released versions of macOS, and the implementation is broken in macOS Monterey. dnsextd.txt Comments welcome

I've tried to find explicit documentation for the role to select when creating an API key for use withxcrun altool --notarize-app --apiKeyBut only found a discussion like Using an API Key with iTMSTransporter. Should it always be App Manager, or is there a less-priviledged one for this task? Notarization doesn't seem like it would require significant access.

Have DriverKit entitlement decisions started being issued? We filled in the form weeks ago and haven't received a response of any kind. We already had a kext entitlement, so I was hoping the request would be a formality.