Hi, We are using the following API from sys/random.h to generate entropy in our module. int getentropy(void* buffer, size_t size); Could you confirm if this API internally uses a non-physical entropy source and adhere to SP800-90B as the following document says: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/entropy/E181_PublicUse.pdf

Hello. I want to do the following and need your help. I want to import a certificate (pkcs#12) into my macOS keychain with a setting that prohibits exporting the certificate. I want to import the certificate (pkcs#12) into my login keychain or system keychain. I was able to achieve [1] with the help of the following threads, but have the following problems. https://developer.apple.com/forums/thread/677314?answerId=824644022#824644022 how to import into login keychain or system keychain How to achieve this without using the deprecated API To import into the login keychain, I could use the “SecKeychainCopyDefault” function instead of the “SecKeychainCopySearchList” function, However, both of these functions were deprecated APIs. https://developer.apple.com/documentation/security/seckeychaincopysearchlist(_:) https://developer.apple.com/documentation/security/seckeychaincopydefault(_:) I checked the following URL and it seems that using the SecItem API is correct, but I could not figure out how to use it. https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains Is there any way to import them into the login keychain or system keychain without using these deprecated APIs?

I'm looking for confirmation on the security aspects of fdesetup authrestart when used on a FileVault-enabled Mac. As I understand it, this command temporarily stores the decryption key in memory to allow the system to restart without requiring manual entry of the FileVault password. However, I have a few security-related concerns: Storage of the Decryption Key: Where exactly is the key stored during an authenticated restart? Is it protected within the Secure Enclave (for Apple Silicon Macs) or the T2 Security Chip on Intel Macs? Key Lifetime & Wiping: At what point is the decryption key erased from memory? Does it persist in any form after the system has fully rebooted? Protection Against Physical Attacks: If an attacker gains physical access to the machine before the restart completes, is there any possibility that they could extract the decryption key from memory? Cold Boot Attack Resistance: Is there any risk that advanced forensic techniques (such as freezing RAM to retain data) could be used to recover the decryption key after issuing an authenticated restart? Malware Resistance: Could a compromised system (e.g., root access by an attacker) intercept or misuse the decryption key before the restart? I understand that on Apple Silicon and T2-equipped Macs, FileVault keys are tied to hardware-based encryption, making unauthorized access difficult. However, I'd like to confirm whether Authenticated Restart introduces any new risks compared to a standard FileVault-enabled boot process.

Hello -- I am developing an Authentication Plug-in for the purpose of invoking login with no user interaction (headless). There seems to be sufficient documentation and sample code on how to implement a plug-in and mechanism, and debug the same, which is great. What I am trying to understand is exactly how to modify the login right (system.login.console) in order to accomplish my goal. Question 1: I had the idea of installing my mechanism as the first mechanism of the login right, and when invoked to set the username and password into the engine’s context, in the belief that this would negate the system from needing to display the login screen. I didn’t modify or remove any other mechanisms. This did not work, in the sense that the login screen was still shown. Should this work in theory? Question 2: I then tried modifying the login right to remove anything that interacted with the user, leaving only the following: <array> <string>builtin:prelogin</string> <string>builtin:login-begin</string> <string>builtin:forward-login,privileged</string> <string>builtin:auto-login,privileged</string> <string>MyAuthPlugin:customauth,privileged</string> <string>PKINITMechanism:auth,privileged</string> <string>builtin:login-success</string> <string>HomeDirMechanism:login,privileged</string> <string>HomeDirMechanism:status</string> <string>MCXMechanism:login</string> <string>CryptoTokenKit:login</string> </array> The mechanisms I removed were: <string>builtin:policy-banner</string> <string>loginwindow:login</string> <string>builtin:reset-password,privileged</string> <string>loginwindow:FDESupport,privileged</string> <string>builtin:authenticate,privileged</string> <string>loginwindow:success</string> <string>loginwindow:done</string> In place of builtin:authenticate I supplied my own mechanism to verify the user’s password using OD and then set the username and password in the context. This attempt appears to have failed quite badly, as authd reported an error almost immediately (I believe it was related to the AuthEngine failing to init). There’s very little information to go on as to what each of these mechanisms do, and which are required, etc. Am I on the wrong track in attempting this? What would be the correct approach?

Hello, I have created an app for both iOs and Android where upon speaking two trigger words, the listening app sends a text and then calls to an inputted designated phone contact. The Android version works perfectly. The iOs version also works perfectly but the iOs app emiits a PopUp for each, the text and then the call asking "Do you really want to send the text -or- make the call". Basically, I input the contact info and I spoke the trigger words. So, yes I want to send the text and make the call. So, I have to click the two PopUps then the device sends and calls. Is there a way to suppress the PopUps in any way? The app is designed for emergencies. So, a dely to anser a popup is not at all good. Maybe by telling the device to allow auto calls and texts from my app? Any and all help on this issue will be very welcomed... Thanks :)

We recently transferred two applications to a different account, both of which utilize Keychain and shared app containers. Before transferring the first application, we anticipated losing access to the Keychain and took proactive measures by backing up data to the app’s private container in the final release prior to the transfer. During the app transfer process, we removed the shared container group ID from the old account and recreated it under the new account. In our testing, Keychain restoration from the local backup was successful, and users experienced no disruptions. However, after releasing the application, we observed that approximately 25% of our users not only lost their Keychain data as expected but also their shared app container data. As we have been unable to reproduce this issue internally, we are seeking your guidance on how to prevent a similar situation when transferring our second application. At this stage, we have not yet released any updates from the new account, and the Keychain data remains backed up in the app’s private container. We would appreciate any insights or recommendations you can provide to ensure a smooth transition for our users and make sure we can keep the data in shared container.

I am working on improving Keychain item storage secured with Face ID using SecAccessControlCreateWithFlags. The implementation uses the .biometryAny flag as shown below: SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, &amp;error ) While this approach generally works as expected, I encountered a specific edge case during testing. On iOS 18.3.1 with Xcode 15.4, the following sequence causes the Keychain item to become inaccessible: Navigate to Settings &gt; Face ID &amp; Passcode and select Reset Face ID. Before setting up a new Face ID, tap the Back button to exit the setup process. Reopen the Face ID setup and complete the enrollment. Return to the app—previously stored Keychain items protected by .biometryAny are no longer available. This behavior appears to be a change introduced in recent iOS versions. In versions prior to iOS 15, resetting or deleting Face ID entries did not invalidate existing Keychain items protected by .biometryAny. This difference in behavior between iOS versions raises questions about the changes to biometric protection handling. Any suggestions are welcomed that might shine a light on what the best practice to use keychain access control and prevent the data to become unavailable.

According to https://developer.apple.com/documentation/security/app_sandbox/discovering_and_diagnosing_app_sandbox_violations it is possible to view detailed violation reports for non-system services. Is it possible to do something similar for system services? I have encountered an issue where several (all?) of my Macbooks get into a sandbox violation situation (I assume). Below is in excerpt from logs focusing just on the sandbox violation. The errors are surrounded by XPC failures and errors. error 23:23:21.382263+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence error 23:23:24.385962+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence error 23:23:27.389910+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence error 23:23:36.408940+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence error 23:23:45.419593+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence error 23:23:54.432109+0100 kernel Sandbox: Family(1316) deny(1) mach-lookup com.apple.contactsd.persistence The above is just an except, and it seems that Family, imagent and searchpartyuseragent are trying to access com.apple.contactsd.persistance once per second or so and failing (there are also some attempts to reach com.apple.timed.xpc, but an insignificant amount in comparison to com.apple.contactsd.persistance). This in turn causes Diagnostics Reporter to start, and then end hastily almost every ten seconds. fault 23:23:05.903908+0100 Diagnostics Reporter Invalid launch. fault 23:23:16.038017+0100 Diagnostics Reporter Invalid launch. fault 23:23:26.136348+0100 Diagnostics Reporter Invalid launch. fault 23:23:36.274543+0100 Diagnostics Reporter Invalid launch. fault 23:23:46.414546+0100 Diagnostics Reporter Invalid launch. I have no idea how I did this, but I seemed to have messed up sandbox access rights to contacts for some system services?

We have 2 developers: Developer A created a Bundle ID and configured Sign in with Apple, but didn't create a corresponding App. This Bundle ID is only used for login on our official website. Developer B created a Bundle ID, configured Sign in with Apple, and has a corresponding App. The issue we're encountering is that because these two Bundle IDs are under different teams, when using the same Apple ID to log into these two applications, different accounts are generated. (We've tested that when creating Service IDs under the same team, logging in with Bundle IDs under the same team generates the same account.) Since Developer A's Bundle ID doesn't have a created app, it cannot be transferred to Developer B. Therefore, we'd like to know if there's any way to make the accounts generated from logging in with the same Apple ID be identical across these two teams?

Hi everyone, I’m currently facing an issue while trying to submit an update for my app to the App Store. The review process is blocking the update due to a "Privacy - Data Use and Sharing" warning, stating that our app requests "tracking purchase history for tracking purposes." However, we have already removed this functionality and deleted the NSUserTrackingUsageDescription key from our latest build. Despite this, the warning persists, and we are unable to proceed with the update. I have already contacted Apple Support, but in the meantime, I wanted to ask the community: Has anyone else encountered this issue, and if so, how did you resolve it? Is there a way to force a refresh of privacy-related settings in App Store Connect? Are there any additional steps we need to take to completely remove this tracking flag from our app submission? Any insights or guidance would be greatly appreciated! Thanks in advance for your help.

I am experiencing an issue with Apple Sign-In on Vision Pro. When I build and run the app from Xcode, everything works fine—after signing in, the app returns to the foreground as expected. However, when I launch the app directly on Vision Pro (not from Xcode), after completing the sign-in process, the app does not reopen from the background automatically. Instead, it closes, and I have to manually tap the app icon to reopen it. Has anyone else encountered this issue? Is there a way to ensure the app properly resumes after sign-in without requiring manual intervention?

I have my custom Authplugin implemented at login (system.login.console), and I want to remove password requirement validation/authentication from system.login.console authorization right. Do you see any functionality loss in completely removing password need at login. And is there any reference which can help me here to acheive this?

Hi, The email attached states that we need to add GoogleToolboxForMac's missing privacy manifest. I received the attached report after running my app privacy report, however it is different and does not include GoogleToolboxForMac. I'm not sure if we need to add the privacy manifest for GoogleToolboxForMac alone or for both of them. If yes, what should I put in my privacy manifest for GoogleToolboxForMac? IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST OR IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST Please reply ASAP Regards, Viharshitha

I have a small command-line app I've been using for years to process files. I have it run by an Automator script, so that I can drop files onto it. It stopped working this morning. At first, I could still run the app from the command line, without Automator. But then after I recompiled the app, now I cannot even do that. When I run it, it's saying 'zsh: killed' followed by my app's path. What is that? The app does run if I run it from Xcode. How do I fix this?

Hi, I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues: The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write. I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder. Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight. An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... It suspect a Gate Keeper problem, but I cannot found any info on the web about how this system could be reset. I tried sudo spctl --reset-default, but it returns This operation is no longer supported... I wonder if these symptoms depend on how the app is archived and could be propagated to my final users, or just related to a corrupted install of Sequoia on my local machine. My feeling is that a signature problem should have been detected by the archive validation, but how could we be sure? Any idea would be greatly appreciated, thanks!

I'm working on a Password Manager app that integrates with the AutoFill Credential Provider to provide stored passwords and OTPs to the user within Safari and other apps. Password AutoFill works perfectly. I'm unable to get iOS to register that the app supports OTPs though. I've followed the Apple documentation here: https://developer.apple.com/documentation/authenticationservices/providing-one-time-passcodes-to-autofill and added "ProvidesOneTimeCodes" to the AutoFill extension's Info.plist, but iOS just doesn't seem to notice the OTP support. &lt;key&gt;ASCredentialProviderExtensionCapabilities&lt;/key&gt; &lt;dict&gt; &lt;key&gt;ProvidesOneTimeCodes&lt;/key&gt; &lt;true/&gt; &lt;key&gt;ProvidesPasswords&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; Any help would be greatly appreicated!

We are working with an iOS app where we have enabled the “Generate Debug Symbols” setting to true in Xcode. As a result, the .dSYM files are generated and utilized in Firebase Crashlytics for crash reporting. However, we received a note in our Vulnerability Assessment report indicating a potential security concern. The report mentions that the .ipa file could be reverse-engineered due to the presence of debug symbols, and that such symbols should not be included in a released app. We could not find any security-related information about this flag, “Generate Debug Symbols,” in Apple’s documentation. Could you please clarify if enabling the “Generate Debug Symbols” flag in Xcode for a production app creates any security vulnerabilities, such as the one described in the report? The report mentions the following vulnerability: TEST-0219: Testing for Debugging Symbols The concern raised is that debugging symbols, while useful for crash symbolication, may be leveraged to reverse-engineer the app and should not be present in a production release. Your prompt confirmation on this matter would be greatly appreciated. Thank you in advance for your assistance.

I have had a password autofill app extension in production for years. It still works fine. Except when the user taps a username or password textfield and selects "AutoFill" from the context menu. They are shown a modal error dialog, stating: "AutoFill Unavailable - The developer needs to update it to work with this feature." I cannot find any help on this issue. The AutoFill extension works fine when tapping the "Passwords" bar above the iOS keyboard. Any pointers would be appreciated.

Hey there, I used our team's account to configure sign in with Apple, the mode is pop up, my clientId scope redirectUrl state are both correct. I got Failed to verify your identity. Try again., actually my account is valid because I can login to my mac and every apple website. I have tried many apple accounts and still got this error. That was so weird, I didn't find a solution online. Pls help me thanks.

I am developing a custom authorization plugin for macOS, and I’ve encountered an issue where the auth plugin view remains visible on the home screen for a few seconds after login. Issue Details: After entering valid credentials, I call setResult(.allow) in my plugin to proceed with login. The authentication succeeds, and macOS starts transitioning to the home screen. However, for a few seconds after login, the authorization plugin view is still visible on the home screen before it disappears. I have observed this issue even when using Apple's sample authorization plugin. Observation: This issue occurs without an external monitor (on a single built-in display). If I manually close the plugin window inside Destroy(AuthPlugin.mechanism), then the auth plugin views do not appear on the home screen, which seems to fix the issue. However, when I do this, a gray screen appears for about a second before the desktop environment fully loads. I suspect that the gray screen appears due to the time macOS takes to fully load the home screen environment after login. Questions: Why does the authorization plugin view persist on the home screen for a few seconds after login? Is manually closing the plugin window in Destroy(AuthPlugin.mechanism) the correct way to prevent this, or is there a better approach? Is my assumption that the gray screen appears due to the home screen not being fully loaded correct? If the gray screen is caused by home screen loading, is there a system notification or event I can listen to in order to know when the home screen has fully loaded?