I regularly help developers with keychain problems, both here on DevForums and for my Day Job™ in DTS. Many of these problems are caused by a fundamental misunderstanding of how the keychain works. This post is my attempt to explain that. I wrote it primarily so that Future Quinn™ can direct folks here rather than explain everything from scratch (-: If you have questions or comments about any of this, put them in a new thread and apply the Security tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" SecItem: Fundamentals or How I Learned to Stop Worrying and Love the SecItem API The SecItem API seems very simple. After all, it only has four function calls, how hard can it be? In reality, things are not that easy. Various factors contribute to making this API much trickier than it might seem at first glance. This post explains the fundamental underpinnings of the keychain. For information about specific issues, see its companion post, SecItem: Pitfalls and Best Practices. Keychain Documentation Your basic starting point should be Keychain Items. If your code runs on the Mac, also read TN3137 On Mac keychain APIs and implementations. Read the doc comments in <Security/SecItem.h>. In many cases those doc comments contain critical tidbits. When you read keychain documentation [1] and doc comments, keep in mind that statements specific to iOS typically apply to iPadOS, tvOS, and watchOS as well (r. 102786959). Also, they typically apply to macOS when you target the data protection keychain. Conversely, statements specific to macOS may not apply when you target the data protection keychain. [1] Except TN3137, which is very clear about this (-: Caveat Mac Developer macOS supports two different keychain implementations: the original file-based keychain and the iOS-style data protection keychain. IMPORTANT If you’re able to use the data protection keychain, do so. It’ll make your life easier. See the Careful With that Shim, Mac Developer section of SecItem: Pitfalls and Best Practices for more about this. TN3137 On Mac keychain APIs and implementations explains this distinction. It also says: The file-based keychain is on the road to deprecation. This is talking about the implementation, not any specific API. The SecItem API can’t be deprecated because it works with both the data protection keychain and the file-based keychain. However, Apple has deprecated many APIs that are specific to the file-based keychain, for example, SecKeychainCreate. TN3137 also notes that some programs, like launchd daemons, can’t use the file-based keychain. If you’re working on such a program then you don’t have to worry about the deprecation of these file-based keychain APIs. You’re already stuck with the file-based keychain implementation, so using a deprecated file-based keychain API doesn’t make things worse. The Four Freedoms^H^H^H^H^H^H^H^H Functions The SecItem API contains just four functions: SecItemAdd(_:_:) SecItemCopyMatching(_:_:) SecItemUpdate(_:_:) SecItemDelete(_:) These directly map to standard SQL database operations: SecItemAdd(_:_:) maps to INSERT. SecItemCopyMatching(_:_:) maps to SELECT. SecItemUpdate(_:_:) maps to UPDATE. SecItemDelete(_:) maps to DELETE. You can think of each keychain item class (generic password, certificate, and so on) as a separate SQL table within the database. The rows of that table are the individual keychain items for that class and the columns are the attributes of those items. Note Except for the digital identity class, kSecClassIdentity, where the values are split across the certificate and key tables. See Digital Identities Aren’t Real in SecItem: Pitfalls and Best Practices. This is not an accident. The data protection keychain is actually implemented as an SQLite database. If you’re curious about its structure, examine it on the Mac by pointing your favourite SQLite inspection tool — for example, the sqlite3 command-line tool — at the keychain database in ~/Library/Keychains/UUU/keychain-2.db, where UUU is a UUID. WARNING Do not depend on the location and structure of this file. These have changed in the past and are likely to change again in the future. If you embed knowledge of them into a shipping product, it’s likely that your product will have binary compatibility problems at some point in the future. The only reason I’m mentioning them here is because I find it helpful to poke around in the file to get a better understanding of how the API works. For information about which attributes are supported by each keychain item class — that is, what columns are in each table — see the Note box at the top of Item Attribute Keys and Values. Alternatively, look at the Attribute Key Constants doc comment in <Security/SecItem.h>. Uniqueness A critical part of the keychain model is uniqueness. How does the keychain determine if item A is the same as item B? It turns out that this is class dependent. For each keychain item class there is a set of attributes that form the uniqueness constraint for items of that class. That is, if you try to add item A where all of its attributes are the same as item B, the add fails with errSecDuplicateItem. For more information, see the errSecDuplicateItem page. It has lists of attributes that make up this uniqueness constraint, one for each class. These uniqueness constraints are a major source of confusion, as discussed in the Queries and the Uniqueness Constraints section of SecItem: Pitfalls and Best Practices. Parameter Blocks Understanding The SecItem API is a classic ‘parameter block’ API. All of its inputs are dictionaries, and you have to know which properties to set in each dictionary to achieve your desired result. Likewise for when you read properties in output dictionaries. There are five different property groups: The item class property, kSecClass, determines the class of item you’re operating on: kSecClassGenericPassword, kSecClassCertificate, and so on. The item attribute properties, like kSecAttrAccessGroup, map directly to keychain item attributes. The search properties, like kSecMatchLimit, control how the system runs a query. The return type properties, like kSecReturnAttributes, determine what values the query returns. The value type properties, like kSecValueRef perform multiple duties, as explained below. There are other properties that perform a variety of specific functions. For example, kSecUseDataProtectionKeychain tells macOS to use the data protection keychain instead of the file-based keychain. These properties are hard to describe in general; for the details, see the documentation for each such property. Inputs Each of the four SecItem functions take dictionary input parameters of the same type, CFDictionary, but these dictionaries are not the same. Different dictionaries support different property groups: The first parameter of SecItemAdd(_:_:) is an add dictionary. It supports all property groups except the search properties. The first parameter of SecItemCopyMatching(_:_:) is a query and return dictionary. It supports all property groups. The first parameter of SecItemUpdate(_:_:) is a pure query dictionary. It supports all property groups except the return type properties. Likewise for the only parameter of SecItemDelete(_:). The second parameter of SecItemUpdate(_:_:) is an update dictionary. It supports the item attribute and value type property groups. Outputs Two of the SecItem functions, SecItemAdd(_:_:) and SecItemCopyMatching(_:_:), return values. These output parameters are of type CFTypeRef because the type of value you get back depends on the return type properties you supply in the input dictionary: If you supply a single return type property, except kSecReturnAttributes, you get back a value appropriate for that return type. If you supply multiple return type properties or kSecReturnAttributes, you get back a dictionary. This supports the item attribute and value type property groups. To get a non-attribute value from this dictionary, use the value type property that corresponds to its return type property. For example, if you set kSecReturnPersistentRef in the input dictionary, use kSecValuePersistentRef to get the persistent reference from the output dictionary. In the single item case, the type of value you get back depends on the return type property and the keychain item class: For kSecReturnData you get back the keychain item’s data. This makes most sense for password items, where the data holds the password. It also works for certificate items, where you get back the DER-encoded certificate. Using this for key items is kinda sketchy. If you want to export a key, called SecKeyCopyExternalRepresentation. Using this for digital identity items is nonsensical. For kSecReturnRef you get back an object reference. This only works for keychain item classes that have an object representation, namely certificates, keys, and digital identities. You get back a SecCertificate, a SecKey, or a SecIdentity, respectively. For kSecReturnPersistentRef you get back a data value that holds the persistent reference. Value Type Subtleties There are three properties in the value type property group: kSecValueData kSecValueRef kSecValuePersistentRef Their semantics vary based on the dictionary type. For kSecValueData: In an add dictionary, this is the value of the item to add. For example, when adding a generic password item (kSecClassGenericPassword), the value of this key is a Data value containing the password. This is not supported in a query dictionary. In an update dictionary, this is the new value for the item. For kSecValueRef: In add and query dictionaries, the system infers the class property and attribute properties from the supplied object. For example, if you supply a certificate object (SecCertificate, created using SecCertificateCreateWithData), the system will infer a kSecClass value of kSecClassCertificate and various attribute values, like kSecAttrSerialNumber, from that certificate object. This is not supported in an update dictionary. For kSecValuePersistentRef: For query dictionaries, this uniquely identifies the item to operate on. This is not supported in add and update dictionaries. Revision History 2025-05-28 Expanded the Caveat Mac Developer section to cover some subtleties associated with the deprecation of the file-based keychain. 2023-09-12 Fixed various bugs in the revision history. Added a paragraph explaining how to determine which attributes are supported by each keychain item class. 2023-02-22 Made minor editorial changes. 2023-01-28 First posted.

Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK. We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect. For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED: acl_get_file(path, ACL_TYPE_EXTENDED) acl_get_fd_np(fd, ACL_TYPE_EXTENDED) On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL. The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability. On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object? Please clarify: Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations. Whether relevant behavior is specific to this macOS/APFS version. Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.

We’re using an Enhanced Security helper extension with AppExtensionProcess and XPCSession to isolate native zero-knowledge proof generation from wallet and signing code. On an iPhone 15 Pro running iOS 26.6.2 (23G90), the helper terminates with: EXC_RESOURCE RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded (limit=35 MB) Terminated due to memory issue Our current prover requires substantially more memory: its public proving key is approximately 402 MiB, and its witness workspace alone is approximately 69 MiB. The same proof engine has completed successfully in a standalone iOS app process. The helper currently processes only synthetic test inputs. We want to preserve the helper’s sandbox and Enhanced Security protections and use a configuration supported for App Store distribution. Is there a supported way to increase the memory limit for this specific helper extension type? Does com.apple.developer.kernel.increased-memory-limit apply to Enhanced Security helper extensions? If so, what provisioning, target configuration, and device/OS requirements apply?

We are developing a security-sensitive local execution system on macOS and need clarification about supported Darwin/APFS filesystem APIs. Our requirement is to create an additional directory entry (hard link) for an existing, authorized regular-file object while retaining its original directory entry. SECURITY REQUIREMENTS The source file has already been opened and its identity verified using a held file descriptor and fstat(). The source must remain the exact same filesystem object (device/inode identity), not a copy or clone. An attacker operating under the same user account may concurrently rename, unlink, or replace the source pathname. The publication operation must not create a hard link to, or otherwise mutate, a substituted source object. The new link must be created within an already-open, authorized destination directory. Unsupported configurations must be detectable before attempting a potentially unsafe publication mutation. The original source directory entry must remain present. We have reviewed linkat(), fclonefileat(), rename-based approaches, filesystem flags, and directory-descriptor-relative operations. The difficulty is that linkat() identifies its source through a pathname. Holding a verified source file descriptor does not appear to guarantee that the pathname still identifies the same object when linkat() performs the mutation. A subsequent fstat() or pathname identity check cannot undo an already-created link to a substituted object. QUESTIONS Does macOS provide a supported public API that creates an additional hard link directly from an existing open file descriptor, without resolving a replaceable source pathname? Does Darwin support an equivalent of Linux linkat() with AT_EMPTY_PATH, or another documented descriptor-based source-linking mechanism? Can any supported macOS filesystem API guarantee that a concurrent same-user replacement of the source directory entry cannot redirect the publication mutation? If descriptor-based hard linking is unavailable, is there a supported filesystem or namespace protection mechanism that prevents same-owner source-entry substitution throughout the operation? Do AT_SYMLINK_FOLLOW, AT_SYMLINK_NOFOLLOW, AT_RESOLVE_BENEATH, AT_RESOLVE_NOFOLLOW_ANY, or related Darwin flags provide any guarantee that the linked source is the previously verified inode rather than a replacement? Are the relevant guarantees dependent on macOS version, APFS volume configuration, filesystem flags, privileges, or entitlements? Is there a supported way to determine whether the required operation and guarantees are available before performing the publication mutation? We are specifically interested in documented and supported APIs, their identity guarantees, availability conditions, and limitations. We are not seeking a workaround based solely on comparing file identities after the operation, copying/cloning the file, or assuming that same-user pathname replacement cannot occur. If no supported public API provides these guarantees, confirmation of that limitation would also be helpful. Thank you.

I’m designing a small, controlled macOS test harness. Two separately signed, sandboxed applications communicate through a UNIX-domain socket in an App Group container. They run as non-root processes in a GUI user session. One application also launches a child that inherits its sandbox and an existing socket descriptor. Is there a documented, supported OS policy that preserves this IPC arrangement while preventing the test processes from retrieving, using or modifying credentials, including items in their own Data Protection Keychain access groups and reachable file-based keychains? The policy must also prevent creating credential stores/items outside the permitted test resources. Using a macOS-style TeamID-prefixed App Group avoids that group providing Keychain sharing, but does not establish denial of the remaining Keychain operations. Empty stores, avoiding API calls and relying on users refusing prompts are insufficient for this requirement. If a different execution context or isolation architecture is required, could you identify the supported mechanism and relevant documentation? I’m seeking platform guidance, without relying on private APIs or unsupported custom sandbox profiles.

I am considering a dedicated macOS .app and am looking for public Apple documentation about the initial creation of its app-specific container by the operating system. The priority is to protect existing application data and settings. Running the proposed app and allowing application-managed storage remain on hold. This question concerns an individual app’s container, rather than an App Group shared container. The target macOS version, bundle identifier, signing configuration, and entitlements are not specified here. Please identify any conditions on which an answer depends. My primary question is: Is there public Apple documentation that identifies what the OS creates during initial container creation, which items are mandatory or conditional, and what triggers their creation? Where documented, I would like to understand their locations, contents, size bounds, and lifetime. For a later assessment, I also need to understand: How the container and its initial contents are associated with a particular .app, including any relevant signing or identity requirements. Whether a public, supported mechanism can permit OS-managed initial container creation while separately preventing subsequent application-managed writes inside that container. Please distinguish OS-managed initial creation from writes performed by application code or frameworks used by the application. Please also identify whether the behavior depends on App Sandbox, entitlements, or the macOS version. Links to documentation describing the supported guarantees and their limits would be especially helpful. If some details are implementation-dependent or undocumented, please distinguish those from documented guarantees. Thank you.

Feedback ID: FB25211847 Since 2026-10-11 the root DNSKEY RRset is signed only by KSK-2024 (key tag 38696). With DNSSEC required using nw_parameters_set_requires_dnssec_validation(parameters, YES), mDNSResponder fetches the full chain (icann.org A/DNSKEY/DS, org DNSKEY/DS, root DNSKEY) from the local resolver. All records are present and all signatures validate. After the root DNSKEY query concludes, no validation result is logged, no result or error is delivered to the getaddrinfo request, and later requests for the same name attach as duplicates to the stuck questions and also never return. Without DNSSEC required, the connection succeeds immediately. Suspected cause: KSK-2024 missing from the built-in trust anchors. Secondary issue: validation failure is not reported to the client; the request hangs indefinitely.

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

This is a pre-implementation question about supported direct Keychain service access, based on documentation and SDK-declaration review. No device/Simulator result, runtime failure, compiled sample or verified signing configuration is being reported. Assumed configurations An embedded, app-specific, non-UI ExtensionFoundation extension, restricted to its containing app's extension point. No unrestricted or third-party extension scope is assumed. A: the extension point requires EnhancedSecurity(true). B: the point definition omits EnhancedSecurity. This is not a claim that B is unsandboxed or equivalent to every configuration explicitly declaring EnhancedSecurity(false). Generic-password items, with valid signed membership in the destination Keychain access group assumed for the question only. If that assumption cannot hold for A or B, please identify the unsupported prerequisite. No real identifiers or profiles are supplied. Version scope The API question concerns iOS 26.0 and later only where the relevant symbols/configurations are supported. In the installed iPhoneOS 27.0 SDK declarations inspected, AppExtensionPoint, EnhancedSecurity and UserInterface have iOS 26.0 availability; some binding conveniences have iOS 26.2 availability. Those are declaration observations, not evidence of Keychain authorization or behavior on any OS release. No runtime comparison or final deployment target is selected. Please specify any finer minimum OS/SDK requirement or version-dependent difference; do not infer older-iOS support from the framework name alone. Question For A and B separately, is each of SecItemCopyMatching, SecItemAdd, SecItemUpdate and SecItemDelete supported directly from the extension process for those items, without forwarding the operation to the containing app? Please distinguish the four operations and, for any supported or conditional case, identify: The public sandbox/service rule and required entitlements, separately from access-group membership. Applicable OS/SDK versions and any device-versus-Simulator or development-versus-distribution limits. Lock state, item accessibility, user-interaction or other prerequisites that change the answer. If a case is unsupported or unspecified, stating that and citing the applicable public documentation would resolve that part of the question. API availability or absence of the EnhancedSecurity requirement alone is not being treated as permission to access the service. This asks for the direct API/service boundary only. Relevant public references https://developer.apple.com/documentation/extensionfoundation/adding-support-for-app-extensions-to-your-app https://developer.apple.com/documentation/extensionfoundation/appextensionpoint/enhancedsecurity https://developer.apple.com/documentation/security/sharing-access-to-keychain-items-among-a-collection-of-apps

Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.

Hello, I'm evaluating a local macOS helper service with a minimum deployment target of macOS 13. The service would communicate over an AF_UNIX SOCK_STREAM socket and must authenticate the signed code identity of the connecting process before accepting an operation. I'm investigating whether LOCAL_PEERTOKEN can provide a reliable audit token associated with the peer of an accepted socket. The public macOS SDK declares LOCAL_PEERTOKEN in sys/un.h, but I haven't found documentation establishing its precise security guarantees or availability across supported macOS versions. My questions are: Is LOCAL_PEERTOKEN a public, supported API on macOS 13 and later? Can it be used with getsockopt() on a file descriptor returned by accept() to retrieve an audit_token_t for the connected peer? At what point is the peer identity captured? Is the returned audit token securely bound to the original connecting process, even if that process exits and its PID is reused? Is the audit token obtained through LOCAL_PEERTOKEN officially supported as input to Security.framework APIs such as SecCodeCopyGuestWithAttributes (using kSecGuestAttributeAudit) or SecTaskCreateWithAuditToken? Does the identity remain trustworthy if the connected socket descriptor is inherited or passed to another process? Are there documented limitations concerning descriptor passing or time-of-check/time-of-use races? What is Apple's recommended public API sequence for verifying the signed code identity of an AF_UNIX peer on macOS 13+, including in an App Sandbox environment? I'm looking for documented security and availability guarantees rather than relying solely on observed behavior. Thank you!

Overview We are investigating repeated "login" Keychain prompts affecting our macOS application on macOS 26.6.x. The issue appears after upgrading an existing installation. A clean uninstall/reinstall of the same version resolves it. Changing the affected Keychain item's Access Control from "Confirm before allowing access" to explicitly allowing our application/process also stops the prompts. On one affected machine, Apple Support observed a securityd crash followed by: SecKeyCreateSignature failed CSSMERR_DL_INVALID_DB_HANDLE Our code uses some legacy SecKeychain* APIs, so we are currently investigating whether this is related. Questions Were there any changes in macOS 26.6.x around securityd, Keychain ACL handling, or legacy SecKeychain* APIs that could explain this? Could an existing Keychain ACL become stale after an application upgrade, even when both versions are signed with the same Developer ID?

Dear TestFlight Team! I am observing an increasing misuse of TestFlight public and private invites to distribute scam, spam, and potentially malicious builds: I had reported this already in December last year via Feedback assistant, but since the malicious behavior has not stopped, I hope that you can forward my bug reports to the right team: FB21379977, FB21845307 In multiple cases, these builds impersonate well-known apps (e.g. ChatGPT, OpenAI, Meta) by changing the app name and icon after an initial TestFlight approval, misleading users into installing software from unrelated developer accounts. I believe this represents a systemic weakness in the TestFlight review and update flow, enabling targeted phishing or malware distribution outside the App Store review process. My bug reports have attached: TestFlight invitation emails (.eml) Screenshots from TestFlight documenting impersonation behavior ⸻ Steps to reproduce Create a new Apple Developer account. Upload an initial, benign app (e.g. a calculator) as version 1.0.0 and obtain TestFlight approval. Upload a second build: without changing the version number increase build number Change the app name to a well-known product (e.g. “ChatGPT”) Change the app icon to match the impersonated product Invite targeted email addresses to the TestFlight group. Recipients receive an official TestFlight invite and are prompted to install the impersonating app. ⸻ Expected results TestFlight builds that significantly change app identity (name, icon, branding) should: Require additional review, or Be blocked from distribution without re-approval. Developer accounts should not be able to impersonate well-known companies (e.g. “OpenAI Platforms LLC”) without verification. Users should be protected from installing TestFlight builds that materially differ from what was originally reviewed. ⸻ Actual results App name and icon can be changed between TestFlight builds without triggering additional review. TestFlight invites can convincingly impersonate trusted brands. Targeted users may reasonably believe they are installing a legitimate beta. This creates a credible vector for: Phishing (credentials, payment details) Data exfiltration Social engineering attacks I did not install the builds to avoid personal risk, but the attached artifacts should allow Apple’s internal teams to reproduce and analyze the behavior safely. Some more examples:

For an existing iOS generic-password Keychain item, what documented public API or query contract can establish that its returned SecAccessControl has no additional authentication, application-password, or operation-specific constraints? The item must remain WhenUnlockedThisDeviceOnly, in an exact access group and identity, and non-synchronizing. An unknown or unverified item must be refused without modifying, deleting, or replacing it. An attribute-only creation with no explicit access-control object can return a SecAccessControl when data and attributes are read. We observed this on an iOS 26.5 Simulator. The returned object compared different from a freshly created zero-flags object. We are not treating either that comparison or a successful no-UI read as proof of its complete constraints. The public interface we reviewed exposes creation and type identification; constraint inspection and serialization appear in private headers. Evaluating one operation also does not describe the item's complete policy. Is there a supported discriminator we have missed? If not, is there a documented creation-provenance and persistent-item-identity contract that establishes this property across relaunch, and what limitations apply to existing or recreated items? Please clarify the supported contract rather than private implementation details. We need to preserve refusal of unverified existing items while using the public Keychain APIs correctly.

Since 11 September 2026, the EU Cyber Resilience Act requires anyone selling software in the EU - including paid iOS and Mac apps - to report actively exploited vulnerabilities in their products: an early warning within 24 hours, a notification within 72 hours, through ENISA's reporting platform. It also covers app versions already on sale. The practical first question for most of us is "does anything I ship depend on a package with a known exploited vulnerability?" I couldn't find a tool that treats Swift Package Manager as a first-class ecosystem, so I wrote a small open-source one: reads Package.resolved (v1-v3) and Podfile.lock writes a CycloneDX 1.6 SBOM (useful later for the CRA technical documentation) checks each pinned package against OSV, and marks findings as exploited if CISA's KEV list or ENISA's EUVD lists them runs locally, in Xcode Cloud or as a GitHub Action, and only fails the build on exploited issues by default pipx install cra-scan GitHub repo (Apache-2.0, no dependencies) Two things worth knowing: micro and small companies can't be fined for missing the 24-hour early warning (Art. 64), but the 72-hour notification still applies. The rest of the CRA (technical file, support period, CE marking) applies from 11 December 2027, and for most apps it's self-assessment. How are others approaching this? Feedback on missed matches is very welcome, especially for CocoaPods, which the tool can't match yet.

On macOS 26.6.2 (build 25G83), arm64, I am using the Security framework through JXA, executed by a static /usr/bin/osascript helper launched from the Codex desktop application's local command environment. A dummy-only test attempts to add one generic-password item to the local file-based login keychain. SecItemAdd returns OSStatus 100001. The system's "security error 100001" command describes this as "UNIX[Operation not permitted]". The helper explicitly opens the login keychain and selects it using kSecUseKeychain for the add operation. Synchronizable and Data Protection Keychain options are false. It supplies an access object created by SecAccessCreate with an empty trusted-application array. What I have confirmed: Keychain open/status calls succeed and report unlocked, readable, and writable. I understand these flags do not establish permission for this individual operation. Attribute-only exact lookups report the dummy item as not found before and after each failed add. Granting narrowly scoped filesystem write permission for the login keychain file through the launching tool did not resolve the failure. I have not performed a comparison outside that restricted execution environment. I have not established whether the cause is the environment, API/ACL configuration, or an OS issue. Is this JXA/Security usage supported for a file-based keychain? Which documented diagnostics can distinguish process/sandbox restrictions from item ACL or authentication requirements? Are there relevant constraints on this query/access-object construction? I am seeking a supported implementation, not a way to disable or bypass security protections. I can provide a dummy-only reproducer without credentials or personal paths.

We recently completed an app transfer between two Apple Developer Program teams. Before releasing the first post-transfer version, we need to verify the update behavior from several specific historical versions signed by the previous team. Our main question is not limited to TestFlight: we would like to know Apple's recommended and supported method for reproducing this update path. Could you clarify the following? What is Apple's recommended and supported method for testing an update from a specific pre-transfer version to the first post-transfer release? Can an archived Ad Hoc IPA signed by the previous team be used as the starting version for this test? Can that IPA be updated by a post-transfer TestFlight, Development, or Ad Hoc build signed by the recipient team? Which of these methods most accurately reproduces an App Store update after an app transfer? For a manual Development or Ad Hoc update, is the previous-application-identifiers entitlement required? If it is required, how should the recipient team request a provisioning profile that authorizes this entitlement? Thank you.

Security concern: To provide a visually appealing transition when launching or leaving an application, iOS introduced a feature that automatically captures a screenshot of the current view when an app is moved to the background. This screenshot is subsequently displayed as a preview in the App Switcher. There is security concern that the app shows sensitive information like activation codes or chat histories in the preview image of the App Switcher Need clarification on the following points: 1.Where exactly are these App Switcher preview screenshots stored on the device filesystem? 2.Can these App Switcher snapshots be accessed on a jailbroken iOS device? 3.Are these snapshots stored inside the application container or in a system-managed location outside the app sandbox? Can any Third party application or tool can access this screenshots in iOS device? 5.Is there any Apple-recommended API, entitlement, or platform-supported mechanism on iOS to prevent screenshots in iOS

In macOS Tahoe 26.7 or Sequoia 15.7.5 (and probably other prior versions), when you install a .pkg, symlinks are followed: i.e. if your payload install a file to /Users/Shared/my-folder and, on the target volume, the /Users/Shared/my-folder item is a symbolic link to /Users/Shared/actual-folder, the file will be installed inside /Users/Shared/actual-folder. It used to be possible to tell the installation framework/mechanism not to follow symbolic links by using the followSymLinks attribute in the raw package PackageInfo file. And in this case, the symbolic link would be replaced by a real directory and the file would be installed where it was supposed to be installed. This attribute is apparently not taken into account anymore by the framework/mechanism. [Q] Is this on purpose or is it a bug (in shove for instance)? If it is on purpose, why was it considered a good idea to always follow symbolic links considering the security issues this can create?

I’m seeing a reproducible code-signing failure on macOS 26.6.2 with Xcode 26.6 while building an iOS XCTest bundle for a physical device. A newly created Apple Development identity is valid and can successfully sign and verify a standalone test binary using /usr/bin/codesign. However, xcodebuild build-for-testing reaches the first XCTest re-sign operation and the macOS Keychain authorization dialog for the same development private key becomes unresponsive after entering the login Keychain password and clicking “Always Allow.” The failing command is effectively: /usr/bin/codesign --force --sign -o runtime --timestamp=none ... libXCTestSwiftSupport.dylib and returns: errSecInternalComponent The exact same development certificate successfully signs a standalone binary immediately beforehand. The build is running from an ordinary logged-in Terminal session, not SSH or CI. After aborting the build, inspection showed the XCTest artifacts retained Apple’s original Software Signing certificate rather than the Development certificate, confirming the re-sign did not complete. I have already recreated the login Keychain once and recreated the Apple Development identity. I do not want to make further Keychain ACL/partition changes without understanding the underlying cause. Question: What diagnostic should I collect to determine why SecurityAgent/codesign cannot complete private-key authorization for the XCTest re-sign operation when direct signing with the same identity succeeds?

https://feedbackassistant.apple.com/feedback/24553094 Security.framework returns NULL from SecPolicyCreateSSL when the directory containing the running executable no longer exists. That commonly happens with "go run" after the go command deletes its temporary build directory while a child process is still running. More details on how to reproduce: https://github.com/golang/go/issues/68557 Golang team rejected my workaround https://github.com/golang/go/pull/80471/changes so we're relying on the macOS team to allow this, unless of course there is a great reason not too. This is problematic when developing applications in golang, especially daemons.