Hi there, I'm trying to use SFAuthorizationPluginView in order to show some fields in the login screen, have the user click the arrow, then continue to show more fields as a second step of authentication. How can I accomplish this? Register multiple SecurityAgentPlugins each with their own mechanism and nib? Some how get MacOS to call my SFAuthorizationPluginView::view() and return a new view? Manually remove text boxes and put in new ones when button is pressed I don't believe 1 works, for the second mechanism ended up calling the first mechanism's view's view() Cheers, -Ken

I have a launch daemon that's using the Endpoint Security framework which also is causing high memory usage (in Activity Monitor memory column shows for example 2GB and Real Memory 11MB) when building a big project in Xcode. Is it some kind of memory caching by the system? leaks -forkCorpse seems to not show any leaks. How can I attach with heap or Instruments without the process being killed with "ENDPOINTSECURITY, Code 2 EndpointSecurity client terminated because it failed to respond to a message before its deadline"?

Quinn, in your post "App Groups: macOS vs iOS: Fight!", you mention that an app must meet at least one of four criteria to access an app group container without user intervention: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. Our app is distributed directly (Developer ID), so it doesn't meet the first two criteria. We already had the app group ID set up to match the iOS ID (without our Team ID) and changing it now would affect our users already-stored data, so criteria C isn't really an option either. That brings us to criteria D. We've added the App Groups Capability to our App ID on the Developer site and creating a Developer ID provisioning profile with this App ID. However, for some reason the App Group Capability is not included in the provisioning profile. How then do we go about satisfying criteria D ("your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D)")? If this is impossible, how can we migrate our user's data away from the affected container?

Hi, how can you authenticate a User through Biometrics with iPhone Passcode as Fallback in the Autofill Credential Provider Extension? In the App it works without a problem. In the Extension I get "Caller is not running foreground" Yeah, it isn't, as it's just a sheet above e.g. Safari. I'd like to avoid having the user setup a Passcode dedicated to my App, especially because FaceID is way faster. Does anybody know how to achieve iOS native Auth in the extension? Please let me know, a code sample would be appreciated. Regards, Mia

Issue Summary I'm encountering a DCError.invalidInput error when calling DCAppAttestService.shared.generateAssertion() in my App Attest implementation. This issue affects only a small subset of users - the majority of users can successfully complete both attestation and assertion flows without any issues. According to Apple Engineer feedback, there might be a small implementation issue in my code. Key Observations Success Rate: ~95% of users complete the flow successfully Failure Pattern: The remaining ~5% consistently fail at assertion generation Key Length: Logs show key length of 44 characters for both successful and failing cases Consistency: Users who experience the error tend to experience it consistently Platform: Issue observed across different iOS versions and device types Environment iOS App Attest implementation Using DCAppAttestService for both attestation and assertion Custom relying party server communication Issue affects ~5% of users consistently Key Implementation Details 1. Attestation Flow (Working) The attestation process works correctly: // Generate key and attest (successful for all users) self.attestService.generateKey { keyId, keyIdError in guard keyIdError == nil, let keyId = keyId else { return completionHandler(.failure(.dcError(keyIdError as! DCError))) } // Note: keyId length is consistently 44 characters for both successful and failing users // Attest key with Apple servers self.attestKey(keyId, clientData: clientData) { result in // ... verification with RP server // Key is successfully stored for ALL users (including those who later fail at assertion) } } 2. Assertion Flow (Failing for ~5% of Users with invalidInput) The assertion generation fails for a consistent subset of users: // Get assertion data from RP server self.assertRelyingParty.getAssertionData(kid, with: data) { result in switch result { case .success(let receivedData): let session = receivedData.session let clientData = receivedData.clientData let hash = clientData.toSHA256() // SHA256 hash of client data // THIS CALL FAILS WITH invalidInput for ~5% of users // Same keyId (44 chars) that worked for attestation self.attestService.generateAssertion(kid, clientDataHash: hash) { assertion, err in guard err == nil, let assertion = assertion else { // Error: DCError.invalidInput if let err = err as? DCError, err.code == .invalidKey { return reattestAndAssert(.invalidKey, completionHandler) } else { return completionHandler(.failure(.dcError(err as! DCError))) } } // ... verification logic } } } 3. Client Data Structure Client data JSON structure (identical for successful and failing users): // For attestation (works for all users) let clientData = ["challenge": receivedData.challenge] // For assertion (fails for ~5% of users with same structure) var clientData = ["challenge": receivedData.challenge] if let data = data { // Additional data for assertion clientData["account"] = data["account"] clientData["amount"] = data["amount"] } 4. SHA256 Hash Implementation extension Data { public func toSHA256() -> Data { return Data(SHA256.hash(data: self)) } } 5. Key Storage Implementation Using UserDefaults for key storage (works consistently for all users): private let keyStorageTag = "app-attest-keyid" func setKey(_ keyId: String) -> Result<(), KeyStorageError> { UserDefaults.standard.set(keyId, forKey: keyStorageTag) return .success(()) } func getKey() -> Result<String?, KeyStorageError> { let keyId = UserDefaults.standard.string(forKey: keyStorageTag) return .success(keyId) } Questions User-Specific Factors: Since this affects only ~5% of users consistently, could there be device-specific, iOS version-specific, or account-specific factors that cause invalidInput? Key State Validation: Is there any way to validate the state of an attested key before calling generateAssertion()? The key length (44 chars) appears normal for both successful and failing cases. Keychain vs UserDefaults: Could the issue be related to using UserDefaults instead of Keychain for key storage? Though this works for 95% of users. Race Conditions: Could there be subtle race conditions or timing issues that only affect certain users/devices? Error Recovery: Is there a recommended way to handle this error? Should we attempt re-attestation for these users? Additional Context & Debugging Attempts Consistent Failure: Users who experience this error typically experience it on every attempt Key Validation: Both successful and failing users have identical key formats (44 character strings) Device Diversity: Issue observed across different device models and iOS versions Server Logs: Our server successfully provides challenges and processes attestation for all users Re-attestation: Forcing re-attestation sometimes resolves the issue temporarily, but it often recurs The fact that 95% of users succeed with identical code suggests there might be some environmental or device-specific factor that we're not accounting for. Any insights into what could cause invalidInput for a subset of users would be invaluable.

Hello, I have encountered several challenges related to System Integrity Protection (SIP) state detection and code signing requirements. I would like to seek clarification and guidance on the proper approach to programmatically determine the SIP state. Here are the issues I’ve encountered: XPC Code Signing Check APIs: APIs like setCodeSigningRequirement and setConnectionCodeSigningRequirement do not work when SIP disabled and that's ok given what SIP is. LaunchCodeRequirement API: When using Process.launchRequirement, the LaunchCodeRequirement API does not function anymore when SIP disabled. The IsSIPProtected requirement behaves in a way that is not clearly documented -- it appears to only apply to pre-installed Apple apps. Legacy APIs: Older APIs like SecCodeCheckValidity are likely to be non-functional, though I haven’t had the chance to validate this yet. Private API Concerns: So to mitigate those limitations I prefer my app to not even try to connect to untrusted XPC or launch untrusted Processes when SIP is disabled. The only way to determine SIP state I could find is a low-level C function csr_get_active_config. However, this function is not declared in any publicly available header file, indicating that it is a private API. Since private APIs cannot be used in App Store-distributed apps and are best avoided for Developer ID-signed apps, this does not seem like a viable solution. Given these limitations, what is the recommended and proper approach to programmatically determine the SIP state in a macOS application? Any insights or guidance would be greatly appreciated. Thank you!

When an app is trying to access identities put in the keychain by cryptotokenkit extension, the user gets asked a permission pop-up which reads 'Token Access Request" would like access a token provided by: " with 2 options 'Don't allow' and 'OK' I accidently clicked "Don't allow" and now can't access identities put in crypto token kit. How can I reset the preference?

I have Authorisation Plugin which talks using XPC to my Launch Daemon to perform privileged actions. I want to protect my XPC service narrowing it to be called from known trusted clients. Now since I want authorisation plugin code which is from apple to call my service, I cannot use my own team id or app group here. I am currently banking on following properties of client connection. Apple Team ID : EQHXZ8M8AV Bundle ID starting with com.apple. Client signature verified By Apple. This is what I have come up with. func isClientTrusted(connection: NSXPCConnection) -> Bool { let clientPID = connection.processIdentifier logInfo("🔍 Checking XPC Client - PID: \(clientPID)") var secCode: SecCode? var secStaticCode: SecStaticCode? let attributes = [kSecGuestAttributePid: clientPID] as NSDictionary let status = SecCodeCopyGuestWithAttributes(nil, attributes, [], &secCode) guard status == errSecSuccess, let code = secCode else { logInfo("Failed to get SecCode for PID \(clientPID)") return false } let staticStatus = SecCodeCopyStaticCode(code, [], &secStaticCode) guard staticStatus == errSecSuccess, let staticCode = secStaticCode else { logInfo("Failed to get SecStaticCode") return false } var signingInfo: CFDictionary? let signingStatus = SecCodeCopySigningInformation(staticCode, SecCSFlags(rawValue: kSecCSSigningInformation), &signingInfo) guard signingStatus == errSecSuccess, let info = signingInfo as? [String: Any] else { logInfo("Failed to retrieve signing info") return false } // Extract and Verify Team ID if let teamID = info["teamid"] as? String { logInfo("XPC Client Team ID: \(teamID)") if teamID != "EQHXZ8M8AV" { // Apple's official Team ID logInfo("Client is NOT signed by Apple") return false } } else { logInfo("Failed to retrieve Team ID") return false } // Verify Bundle ID Starts with "com.apple." if let bundleID = info["identifier"] as? String { logInfo("XPC Client Bundle ID: \(bundleID)") if !bundleID.hasPrefix("com.apple.") { logInfo("Client is NOT an Apple system process") return false } } else { logInfo("Failed to retrieve Bundle Identifier") return false } // Verify Apple Code Signature Trust var trustRequirement: SecRequirement? let trustStatus = SecRequirementCreateWithString("anchor apple" as CFString, [], &trustRequirement) guard trustStatus == errSecSuccess, let trust = trustRequirement else { logInfo("Failed to create trust requirement") return false } let verifyStatus = SecStaticCodeCheckValidity(staticCode, [], trust) if verifyStatus != errSecSuccess { logInfo("Client's signature is NOT trusted by Apple") return false } logInfo("Client is fully verified as Apple-trusted") return true } Q: Just wanted community feedback, is this correct approach?

We are developing a captive portal for a community Wi-Fi service that will be deployed to thousands of locations around the world. The service is a paid service that sells Wi-Fi connectivity by data volume rather than time. We want to enable our customers to Sign in with Apple without giving them full internet access until they have made a purchase. This requires us to whitelist domains and URLs to make this work. Where can I find a complete list of domains that are required for Sign in with Apple to function correctly? It’s not possible for us to whitelist *.apple.com because that results in significant (free) background network traffic during the sign in process. So far we have whitelisted: account.apple.com appleid.apple.com appleid.apple-cdn.com idmsa.apple.com gsa.apple.com mzstatic.com Our customers are still having issues with Sign in with Apple while interacting with our captive portal in the iOS pseudo browser. How can we debug this because we cannot use the Safari developer tools with the pseudo browser. Are there any logs when doing this on a Mac that we can check in the Console? If we kick the user out to Safari then they are able to complete the Sign in with Apple process, but that is not the user experience we want.

I am developing a sample authorization plugin to sync the user’s local password to the network password. During the process, I prompt the user to enter both their old and new passwords in custom plugin. After the user enters the information, I use the following code to sync the passwords: try record.changePassword(oldPssword, toPassword: newPassword) However, I have noticed that this is clearing all saved keychain information, such as web passwords and certificates. Is it expected behavior for record.changePassword to clear previously stored keychain data? If so, how can I overcome this issue and ensure the keychain information is preserved while syncing the password? Thank you for your help!

I'm writing an app on macOS that stores passwords in the Keychain and later retrieves them using SecItemCopyMatching(). This works fine 90% of the time. However, occasionally, the call to SecItemCopyMatching() fails with errSecAuthFailed (-25293). When this occurs, simply restarting the app resolves the issue; otherwise, it will consistently fail with errSecAuthFailed. What I suspect is that the Keychain access permission has a time limitation for a process. This issue always seems to arise when I keep my app running for an extended period.

I had the following code in a program that I used to encrypt some important files. I haven't run it in a few years. It used to work, and now it seems the password is mysteriously gone from my Keychain! The return value is now errSecItemNotFound. I'm upset with myself for not backing up the key/password somewhere else. Is there anywhere this could be hiding? Did Apple move it somewhere? I know they created this "Passwords" app in recent years, but I don't see anything in there with the "account" string I used. I run the app from Xcode, so maybe it is in the "container" data somewhere? I do see keychain files under ~/Library. Maybe there is a way to look through old Time Machine backups. Ug. So stressful. Just looking for pointers on where the data might be, and why it might have disappeared. Unfortunately it was not a "guessable" password, it was a generated 256 bit key, base64 encoded. Perhaps I could crack that with brute force if I'm determined enough... public static func queryGenericPasswordAsString(account: String) throws -> String { let query: [String: Any] = [kSecClass as String: kSecClassGenericPassword, kSecMatchLimit as String: kSecMatchLimitOne, kSecAttrAccount as String: account, kSecReturnAttributes as String: true, kSecReturnData as String: true] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) guard status != errSecItemNotFound else { throw KeychainError.noPassword } ... }

I am developing an Authorisation Plugin which talks to Launch daemons over XPC. Above is working neat, now I have to decide on how to get it installed on a machine. Installation requires. Plugin Installation Launch Daemon Installation Both require Moving binary and text (.plist) file into privileged system managed directory. Firing install/load commands as root (sudo). I have referred this post BSD Privilege Escalation on macOS, but I am still not clear how to approach this. Q: My requirement is: I can use .pkg builder and install via script, however I have some initialisation task that needs to be performed. User will enter some details talk to a remote server and get some keys, all goes well restarts the system and my authorisation plugin will welcome him and get him started. If I cannot perform initialisation I will have to do it post restart on login screen which I want to avoid if possible. I tried unconventional way of using AppleScript from a SwiftUI application to run privileged commands, I am fine if it prompts for admin credentials, but it did not work. I don't want that I do something and when approving it from Apple it gets rejected. Basically, how can I provide some GUI to do initialisation during installation or may be an app which helps in this. Q: Please also guide if I am doing elevated actions, how will it affect app distribution mechanism. In Read Me for EvenBetterAuthorizationSample I read it does. Thanks.

Problem Statement: Pre-requisite is to generate a PKCS#12 file using openssl 3.x or above. Note: I have created a sample cert, but unable to upload it to this thread. Let me know if there is a different way I can upload. When trying to import a p12 certificate (generated using openssl 3.x) using SecPKCS12Import on MacOS (tried on Ventura, Sonoma, Sequoia). It is failing with the error code: -25264 and error message: MAC verification failed during PKCS12 import (wrong password?). I have tried importing in multiple ways through, Security Framework API (SecPKCS12Import) CLI (security import &lt;cert_name&gt; -k ~/Library/Keychains/login.keychain -P "&lt;password&gt;”) Drag and drop in to the Keychain Application All of them fail to import the p12 cert. RCA: The issues seems to be due to the difference in the MAC algorithm. The MAC algorithm used in the modern certs (by OpenSSL3 is SHA-256) which is not supported by the APPLE’s Security Framework. The keychain seems to be expecting the MAC algorithm to be SHA-1. Workaround: The current workaround is to convert the modern p12 cert to a legacy format (using openssl legacy provider which uses openssl 1.1.x consisting of insecure algorithms) which the SecPKCS12Import API understands. I have created a sample code using references from another similar thread (https://developer.apple.com/forums/thread/723242) from 2023. The steps to compile and execute the sample is mentioned in the same file. PFA the sample code by the name “pkcs12_modern_to_legacy_converter.cpp”. Also PFA a sample certificate which will help reproduce the issue by the name “modern_certificate.p12” whose password is “export”. Questions: Is there a fix on this issue? If yes, pls guide me through it; else, is it expected to be fixed in the future releases? Is there a different way to import the p12 cert which is resistant to the issue? This issue also poses a security concerns on using outdated cryptographic algorithms. Kindly share your thoughts. pkcs12_modern_to_legacy_converter.cpp

Hi, I'm working on developing my own CryptoTokenKit (CTK) extension to enable codesign with HSM-backed keys. Here's what I’ve done so far: The container app sets up the tokenConfiguration with TKTokenKeychainCertificate and TKTokenKeychainKey. The extension registers successfully and is visible via pluginkit when launching the container app. The virtual smartcard appears when running security list-smartcards. The certificate, key, and identity are all visible using security export-smartcard -i [card]. However, nothing appears in the Keychain. After adding logging and reviewing output in the Console, I’ve observed the following behavior when running codesign: My TKTokenSession is instantiated correctly, using my custom TKToken implementation — so far, so good. However, none of the following TKTokenSession methods are ever called: func tokenSession(_ session: TKTokenSession, beginAuthFor operation: TKTokenOperation, constraint: Any) throws -> TKTokenAuthOperation func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool func tokenSession(_ session: TKTokenSession, sign dataToSign: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, decrypt ciphertext: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, performKeyExchange otherPartyPublicKeyData: Data, keyObjectID objectID: Any, algorithm: TKTokenKeyAlgorithm, parameters: TKTokenKeyExchangeParameters) throws -> Data The only relevant Console log is: default 11:31:15.453969+0200 PersistentToken [0x154d04850] invalidated because the client process (pid 4899) either cancelled the connection or exited There’s no crash report related to the extension, so my assumption is that ctkd is closing the connection for some unknown reason. Is there any way to debug this further? Thank you for your help.

In one of our applications we use LAContext's evaluatePolicy:localizedReason:reply: to authenticate a user. This works pretty well with both username/password and Touch ID. Now we have a request to add support for smart cards and I wonder if this is possible using LAContext. Otherwise I would use Authentication Services, although that might be a bit overkill since we don't need to request any rights, we just want to see that the user has been successfully authenticated. Or is there a better way? Any help would be greatly appreciated. Thanks, Marc

Hi, when creating a CryptoTokenKit extension according to https://developer.apple.com/documentation/cryptotokenkit/authenticating-users-with-a-cryptographic-token, it is neccessary to register it under the securityagent in order to make the CTK usable before login. i.e. we want to run sudo -u _securityagent /Applications/HostApp.app/Contents/MacOS/HostApp However, even with the empty application the command fails with illegal hardware instruction sudo -u _securityagent /Applications/HostApp.app/Contents/MacOS/HostApp I see that it always crashes when the HostApp is sandboxed, but it does not work even without sandboxing (i am sharing the error report message below). i actually noticed that when the HostApp is sandboxed and I run the above command, the extension starts to be usable even before login, even though i see the HostApp crash. The same does not happen without the sandbox So I am curious how to in fact properly register the CTK extension under security agent? Also am not sure how to unregister it from the _securityagent thank you for your help Version: 1.0 (1) Code Type: X86-64 (Native) Parent Process: Exited process [9395] Responsible: Terminal [399] User ID: 92 Date/Time: 2025-03-21 18:54:03.0684 +0100 OS Version: macOS 15.3.2 (24D81) Report Version: 12 Bridge OS Version: 9.3 (22P3060) Anonymous UUID: 41F9918C-5BCA-01C7-59C2-3E8CFC3F8653 Sleep/Wake UUID: 8AB66C75-3C32-41D4-9BD4-887B0FB468FE Time Awake Since Boot: 4300 seconds Time Since Wake: 1369 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: WMClientWindowManager Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [9396] Application Specific Signatures: API Misuse Thread 0 Crashed:: Dispatch queue: WMClientWindowManager 0 libxpc.dylib 0x7ff80667b2bd _xpc_api_misuse + 113 1 libxpc.dylib 0x7ff80665f0e4 xpc_connection_set_target_uid + 187 2 WindowManagement 0x7ffd0b946693 -[WMClientWindowManager _createXPCConnection] + 1011 3 WindowManagement 0x7ffd0b947361 -[WMClientWindowManager _xpcConnection] + 65 4 WindowManagement 0x7ffd0b9447c9 __31-[WMClientWindowManager stages]_block_invoke + 41 5 libdispatch.dylib 0x7ff8067af7e2 _dispatch_client_callout + 8 6 libdispatch.dylib 0x7ff8067bca2c _dispatch_lane_barrier_sync_invoke_and_complete + 60 7 WindowManagement 0x7ffd0b9446fc -[WMClientWindowManager stages] + 268 8 AppKit 0x7ff80b1fd0b7 __54-[NSWMWindowCoordinator initializeStageFramesIfNeeded]_block_invoke + 30 9 libdispatch.dylib 0x7ff8067af7e2 _dispatch_client_callout + 8 10 libdispatch.dylib 0x7ff8067b0aa2 _dispatch_once_callout + 20 11 AppKit 0x7ff80b1fd060 -[NSWMWindowCoordinator initializeStageFramesIfNeeded] + 296 12 AppKit 0x7ff80a3b3701 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 888 13 AppKit 0x7ff80a3b2f77 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1222 14 AppKit 0x7ff80a3b2aa9 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42 15 SwiftUI 0x7ff917f321e0 0x7ff91776f000 + 8139232 16 SwiftUI 0x7ff917a8e2f2 0x7ff91776f000 + 3273458 17 SwiftUI 0x7ff917bccfba 0x7ff91776f000 + 4579258 18 SwiftUI 0x7ff917f2ca8e 0x7ff91776f000 + 8116878 19 SwiftUI 0x7ff917f24a65 0x7ff91776f000 + 8084069 20 SwiftUI 0x7ff917f21540 0x7ff91776f000 + 8070464 21 SwiftUI 0x7ff91849e9f1 0x7ff91776f000 + 13826545 22 SwiftUICore 0x7ffb13103ea5 0x7ffb12c81000 + 4730533 23 SwiftUICore 0x7ffb13102e0f 0x7ffb12c81000 + 4726287 24 SwiftUI 0x7ff91849e903 0x7ff91776f000 + 13826307 25 SwiftUI 0x7ff91849bc1c 0x7ff91776f000 + 13814812 26 AppKit 0x7ff80a54f191 -[NSApplication _doOpenUntitled] + 422 27 AppKit 0x7ff80a4efc59 __58-[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:]_block_invoke + 237 28 AppKit 0x7ff80a963818 __102-[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:withFullFidelity:completionHandler:]_block_invoke + 101 29 AppKit 0x7ff80a4ef6fa __97-[NSDocumentController(NSInternal) _autoreopenDocumentsIgnoringExpendable:withCompletionHandler:]_block_invoke_3 + 148 30 AppKit 0x7ff80a4eee8f -[NSDocumentController(NSInternal) _autoreopenDocumentsIgnoringExpendable:withCompletionHandler:] + 635 31 AppKit 0x7ff80a96373d -[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:withFullFidelity:completionHandler:] + 269 32 AppKit 0x7ff80a3a6259 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 529 33 AppKit 0x7ff80a3a5eb9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 679 34 Foundation 0x7ff807a4b471 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 307 35 Foundation 0x7ff807a4b285 _NSAppleEventManagerGenericHandler + 80 36 AE 0x7ff80e0e4e95 0x7ff80e0da000 + 44693 37 AE 0x7ff80e0e4723 0x7ff80e0da000 + 42787 38 AE 0x7ff80e0de028 aeProcessAppleEvent + 409 39 HIToolbox 0x7ff81217b836 AEProcessAppleEvent + 55 40 AppKit 0x7ff80a39ee6a _DPSNextEvent + 1725 41 AppKit 0x7ff80adf38b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1290 42 AppKit 0x7ff80a38faa9 -[NSApplication run] + 610 43 AppKit 0x7ff80a362d34 NSApplicationMain + 823 44 SwiftUI 0x7ff9177a7da1 0x7ff91776f000 + 232865 45 SwiftUI 0x7ff917af0d40 0x7ff91776f000 + 3677504 46 SwiftUI 0x7ff917d8fef8 0x7ff91776f000 + 6426360 47 Crescendo CryptoTokenKit 0x10b1baf6e static HostApp.$main() + 30 48 Crescendo CryptoTokenKit 0x10b1bd2f9 main + 9 (HostApp.swift:24) 49 dyld 0x7ff8065c82cd start + 1805

In the macOS 14.0 SDK, environment and library constraints were introduced, which made defense against common attack vectors relatively simple (especially with the LightWeightCodeRequirements framework added in 14.4). Now, the application I'm working on must support macOS 13.0 too, so I was looking into alternatives that do work for those operating systems as well. What I found myself is that the SecCode/SecStaticCode APIs in the Security Framework do offer very similar fashion checks as the LightWeightCodeRequirements framework does: SecCodeCopySigningInformation can return values like signing identifier, team identifier, code requirement string and so on. SecStaticCodeCreateWithPath can return a SecStaticCode object to an executable/app bundle on the file system. Let's say, I would want to protect myself against launchd executable swap. From macOS 14.0 onward, I would use a Spawn Constraint for this, directly in the launchd.plist file. Before macOS 14.0, I would create a SecStaticCode object for the executable path found in the launchd.plist, and then examine its SecCodeCopySigningInformation dictionary. If the expectations are met, only then would I execute the launchd.plist-defined executable or connect to it via XPC. Are these two equivalent? If not, what are the differences?

Hi everyone, I’ve been working on storing keys and passwords in the macOS Keychain using the Keychain Services API. Specifically, I’m leveraging SecAccessControlCreateWithFlags to bind items to access control flags, and overall, it’s been working smoothly. I have a question regarding the .applicationPassword flag of SecAccessControlCreateWithFlags. While it successfully prompts the user to input a password, there are no apparent password rules, even a simple “1” is accepted. My questions are: Is there a way to enforce strong password requirements when using the .applicationPassword flag? If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input? With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain, is there a way to store it in a file-based Keychain while marking it as unexportable? I appreciate any insights or suggestions. Thank you! Neil

Hi, I am creating a custom login window, so I am using SFAuthorizationpluginView, here I want to hide Submit Arrow botton which gets displayed beside username and password text feild , is there a way to hide this, please suggest.