Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users.
I did some research on this and understand that an MDM solution can apply these patches without user intervention.
Are there any other ways we can achieve this? Any leads are much appreciated.
General
RSS for tagPrioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi,
I am working on Authorisation Plugin for Mac OS X and able to get going for most of the parts and taking inspiration from Jamf Authorisation Plugin repo https://github.com/jamf/NoMADLogin-AD.
I have seen in project they are implementing logic for following.
Connecting to Wifi
Power management (Sleep, Restart, Power Off)
Question: I was wondering these things need to be implemented or is there a way some components from Mac OS X could be integrated calling some API and I don't have to implement them and I see say a top bar where these items are viable as we see in default login screen.
I have developed my own login screen and I do see it is all blank everything I have to implement from scratch.
Trying luck here if any API is out there to reduce work, else no option but to implement all logic.
I'll really appreciate if someone just could help me know such API's are present or not. In case there are will save lot of effort.
Thanks,
Hi,
A user logs in to the file vault, and DisableFDEAutoLogin is false. The file vault login succeeds, but the login to the selected user fails. The user gets the login screen again. If the user puts an invalid password to try and login again, the loginwindow:FDESupport plugin will change the user's password to the invalid one.
I have 2 basic questions related to Launch Constraints:
[Q1] Are Launch Constraints supposed to work when SIP is disabled?
From what I'm observing, when SIP is disabled, Launch Constraints (e.g. Launch Constraint Parent Process) are not enforced. I can understand that. But it's a bit confusing considering that the stack diagram in the WWDC 2023 session is placing the 'Environment Constraints' block under SIP, not above.
Also the documentation only mentions SIP for the 'is-sip-protected' fact.
[Q2] Is the SpawnConstraint key in legacy launchd plist files (i.e. inside /Library/Launch(Agents|Daemons)) officially supported?
From what I'm seeing, it seems to be working when SIP is enabled. But the WWDC session and the documentation don't really talk about this case.
We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that.
That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above.
(1) In a launch daemon (running thus as root), we do:
let key = SecureEnclave.P256.Signing.PrivateKey()
(2) We then use
key.dataRepresentation
to store a reference to the key in the system keychain as a kSecClassGenericPassword.
(3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using:
SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data)
(4) We then use the output of the above to sign whatever we want.
My questions:
in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key?
if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)?
does the above work, but is not an approach sanctioned by Apple?
Any feedback on this would be greatly appreciated.
Hello everyone,
I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow.
However, on the current beta, I've observed the following:
1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected.
2 I completely uninstalled the application.
3 I then reinstalled the app.
Unexpected Result:
The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation.
My question:
Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta?
Any information or confirmation on this behavior would be greatly appreciated.
Hi everyone,
I'm experiencing an intermittent issue with Keychain data loss on the latest iOS Beta 2. In about 7% of cases, users report that previously saved Keychain items are missing when the app is relaunched — either after a cold start or simply after being killed and reopened.
Here are the key observations:
The issue occurs sporadically, mostly once per affected user, but in 3 cases it has happened 4 times.
No explicit deletion is triggered from the app.
No system logs or error messages from Apple indicate any Keychain-related actions.
The app attempts to access Keychain items, but they are no longer available.
This behavior is inconsistent with previous iOS versions and is not reproducible in development environments.
This raises concerns about:
Whether this is a bug in the beta or an intentional change in Keychain behavior.
Whether this could affect production apps when the final iOS version is released.
The lack of any warning or documentation from Apple regarding this behavior.
Has anyone else encountered similar issues? Any insights, workarounds, or official clarification would be greatly appreciated.
Thanks!
Topic:
Privacy & Security
SubTopic:
General
Hi all,
I’m building a macOS-native C++ trading bot, compiled via Xcode. It sends REST API requests to a crypto exchange (Bitvavo) that require HMAC-SHA256 signatures using a pre-sign string (timestamp + method + path + body) and an API secret.
Here’s the issue:
• The exact same pre-sign string and API secret produce valid responses when signed using Python (hmac.new(secret, msg, hashlib.sha256)),
• But when I generate the HMAC signature using C++ (HMAC(EVP_sha256, ...) via OpenSSL), the exchange returns an invalid signature error.
Environment:
• Xcode 15.3 / macOS 14.x
• OpenSSL installed via Homebrew
• HMAC test vectors match Python’s output for basic strings (so HMAC lib seems correct)
Yet when using the real API keys and dynamic timestamped messages, something differs enough to break verification — possibly due to UTF-8 encoding, memory alignment, or newline handling differences in the Xcode C++ runtime?
Has anyone experienced subtle differences between Python and C++ HMAC-SHA256 behavior when compiled in Xcode?
I’ve published a GitHub repo for reproducibility:
🔗 https://github.com/vanBaardewijk/bitvavo-cpp-signature-test
Thanks in advance for any suggestions or insights.
Sascha
Hi. We're writing Authorization Plugin and started with NullAuthPlugin compilation. When tried to run it on VM (Sonoma 14.6, SIP enabled), we're going into the following issue:
`2025-03-08 13:38:20.699503-0800 0xdcb0 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) [com.apple.MobileFileIntegrity:library_validation_failure] Library Validation failed: Rejecting '/Library/Security/SecurityAgentPlugins/NullAuthPlugin.bundle/Contents/MacOS/NullAuthPlugin' (Team ID: ABCD12EF34, platform: no) for process 'SecurityAgentHel(2094)' (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not'
As I understand, the platform binary is the one signed with Apple signature, which indeed is unavailable for us.
How can we avoid this issue and run the plugin? Perhaps we're missing some build setting requirement?
I am using the CryptoKit SecureEnclave enum to generate Secure Enclave keys. I've got a couple of questions:
What is the lifetime of these keys?
When I don't store them somewhere, how does the Secure Enclave know they are gone? Do backups impact these keys? I.e. can I lose access to the key when I restore a backup?
Do these keys count to the total storage capacity of the Secure Enclave?
If I recall correctly, the Secure Enclave has a limited storage capacity. Do the SecureEnclave key instances count towards this storage capacity?
What is the dataRepresentation and how can I use this?
I'd like to store the Secure Enclave (preferably not in the Keychain due to its limitations). Is it "okay" to store this elsewhere, for instance in a file or in the UserDefaults?
Can the dataRepresentation be used in other apps?
If I had the capability of extracting the dataRepresentation as an attacker, could I then rebuild that key in my malicious app, as the key can be rebuilt with the Secure Enclave on the same device, or are there measures in place to prevent this (sandbox, bundle id, etc.)
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 am developing a daemon-based product that needs a cryptographic, non-spoofable proof of machine identity so a remote management server can grant permissions based on the physical machine.
I was thinking to create a signing key in the Secure Enclave and use a certificate signed by that key as the machine identity. The problem is that the Secure Enclave key I can create is only accessible from user context, while my product runs as a system daemon and must not rely on user processes or launchAgents.
Could you please advise on the recommended Apple-supported approaches for this use case ?
Specifically, Is there a supported way for a system daemon to generate and use an unremovable Secure Enclave key during phases like the pre-logon, that doesn't have non user context (only the my application which created this key/certificate will have permission to use/delete it)
If Secure Enclave access from a daemon is not supported, what Apple-recommended alternatives exist for providing a hardware-backed machine identity for system daemons?
I'd rather avoid using system keychain, as its contents may be removed or used by root privileged users.
The ideal solution would be that each Apple product, would come out with a non removable signing certificate, that represent the machine itself (lets say that the cetificate name use to represent the machine ID), and can be validated by verify that the root signer is "Apple Root CA"
When we enable 3rd party authentication plugin using SFAuthorization window, then when user performs Lock Screen and then unlock the MAC. Now after unlock, if user tries to open Keychain Access, it is not getting opened.
When trying to open Keychain Access, we are prompted for credentials but after providing the credentials Keychians are not getting opened.
This is working on Sonoma 14.6.1 , but seeing this issue from macOS Sequoia onwards.
Are there any suggested settings/actions to resolve this issue?
Hello,
I have an application which uses a helper[1] to download[2] files. When files download is a DMG and user mounts the image to run the application from this DMG it doesn't pass Gatekeeper. It presents the "Application XYZ.app can't be opened.".
Same file downloaded via Safari shows a different dialog, the "XYZ.app is an app downloaded from the internet. Are you sure you want to open it?"
In the system log I see this line:
exec of /Volumes/SampleApp/SampleApp.app/Contents/MacOS/SampleApp denied since it was quarantined by Download\x20Helper and created without user consent, qtn-flags was 0x00000187
The application is running sandboxed and hardened, the main application has com.apple.security.files.downloads.read-write entitlement. Everything is signed by DeveloperID and passes all checks[3].
I tried to check the responsible process[4] of the helper. Then trivial stuff like download folder access in System Settings/Privacy & Security/Files & Folders. Everything seems to be fine.
For what it worths the value of quarantine attribute is following:
com.apple.quarantine: 0087;6723b80e;My App;
The Safari downloaded one posses:
com.apple.quarantine: 0083;6723b9fa;Safari;02162070-2561-42BE-B30B-19A0E94FE7CA
Also tried a few more ways and got to 0081 with Edge and 0082 with a sample app with similar setup. Not sure if that has any meaning.
What could I be doing wrong that Gatekeeper right away refuses to run the application from DMG instead of showing the dialog like in other cases?
[1] The executable is in application bundle located in Contents/Helpers/DownloadHelper.app in the main application bundle.
[2] Nothing fancy, curl + regular POSIX file operations
[3] codesign, syspolicy_check, spctl
[4] launchctl procinfo pid
We have a macOS app that has a Photos Extension, which shares documents with the app via an app group container. Historically we used to have an iOS-style group identifier (group.${TeamIdentifier}${groupName}), because we were lead by the web interface in the developer portal to believe this to be the right way to name groups.
Later with the first macOS 15 betas last year there was a bug with the operating system warning users, our app would access data from different apps, but it was our own app group container directory.
Therefore we added a macOS-style group identifier (${TeamIdentifier}${groupName}) and wrote a migration of documents to the new group container directory.
So basically we need to have access to these two app group containers for the foreseeable future.
Now with the introduction of iOS-style group identifiers for macOS, Xcode Cloud no longer archives our app for TestFlight or AppStore, because it complains:
ITMS-90286: Invalid code signing entitlements - Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.${TeamIdentifier}${groupName}, ${TeamIdentifier}${groupName}]” value for the com.apple.security.application-groups key in isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s).
We have included the iOS-style group identifier in the provisioning profile, generated automatically, but can't do the same for the macOS-style group identifier, because the web interface only accepts identifiers starting with "group".
How can we get Xcode Cloud to archive our app again using both group identifiers?
Thanks in advance
Using the simplified sign-in with tvOS and a third party password manager, I receive a complete ASPasswordCredential, and I can easily log into my app. When I do the same thing but with Apple's password manager as the source, I receive an ASPasswordCredential that includes the email address, but the password is an empty string.
I have tried deleting the credentials from Apple Passwords and regenerating them with a new login to the app's website. I have tried restarting my iPhone.
Is this the expected behavior? How should I be getting a password from Apple's Password app with an ASAuthorizationPasswordRequest?
Trying to validate external reference identifiers with SecTrustEvaluateWithError Method by setting reference Ids to SecPolicyCreateSSL() & SecPolicyCreateWithProperties()
But two concerns are -
Validates for correct reference IDs but gives error for combination of wrong & correct reference Ids
398 days validity works mandatorily before reference Ids check.
Is there any other to validate external reference Ids?, which give flexibility
To pass multiple combinations of reference IDs string (wrong, correct, IP, DNS)
To validate reference ID without days validity of 398.
Please suggest. Any help here is highly appreciated.
Hi everyone,
I’d like to clarify something regarding the behavior of Team IDs after an app transfer between Apple Developer accounts.
I have an app update that enforces a force update for all users. My plan is to release this update under the current developer account, and then proceed with transferring the app to a different developer account shortly afterward.
My concern is: once the transfer is complete, will users who download the same app version (released before the transfer) be logged out due to a change in Team ID? Specifically, does the transferred app continue to use the original Team ID (used to sign the last submitted build), or does the Team ID change immediately upon transfer — affecting Keychain access?
Any insights or confirmation on this would be greatly appreciated. Thanks!
Topic:
Privacy & Security
SubTopic:
General
Hi all,
I'm using a CryptoTokenKit (CTK) extension to perform code signing without having the private key stored on my laptop. The extension currently only supports the rsaSignatureDigestPKCS1v15SHA256 algorithm:
func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool {
return algorithm.isAlgorithm(SecKeyAlgorithm.rsaSignatureDigestPKCS1v15SHA256)
}
This setup works perfectly with codesign, and signing completes without any issues.
However, when I try to use productsign, the system correctly detects and delegates signing to my CTK extension, but it seems to always request rsaSignatureDigestPKCS1v15SHA1 instead:
productsign --timestamp --sign <identity> unsigned.pkg signed.pkg
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: <org> (<team>)" from keychain (null)
...
Error Domain=NSOSStatusErrorDomain Code=-50
"algid:sign:RSA:digest-PKCS1v15:SHA1: algorithm not supported by the key"
...
productsign: error: Failed to sign the product.
From what I understand, older versions of macOS used SHA1 for code signing, but codesign has since moved to SHA256 (at least when legacy compatibility isn't a concern). Oddly, productsign still seems to default to SHA1, even in 2025.
Is there a known way to force productsign to use SHA256 instead of SHA1 for the signature digest algorithm? Or is there some flag or configuration I'm missing?
Thanks in advance!
I am developing a MacOS Authorisation Plugin, I have username and password entry items and utilising SFAuthorizationPluginView to display that. I am able to do so.
Requirement is I have to store ed25519 private key in PEM format in System Keychain as I need to read this entry before login to sign a request to a remote server.
I only want my authorisation plugin to access this private key in System Keychain.
I am looking up resources on the internet but I could not find specific to macOS Authorisation plugin, many are specific to iOS and some point at using entitlements and app group, but I doubt that applies to macOS authorisation plugin.
I'll really appreciate if some pointers are shared how can I store a private credential in System Keychain so that it can be used by only my plugin only, and this is before I have logged into the system.