SecTrustedApplicationCreateFromPath replacement

Hi,


I'm working on the macOS app that automates identities importing from .developerProfile format. To make imported keys work correctly I have to change the list of trusted applications.

SecTrustedApplicationCreateFromPath becomes deprecated API since 10.15 so I become unsafe to use it today. There are no information in the documentation about new approaches for changing ACLs applications. Can you point me in the right direction?

There is no direct replacement for

SecTrustedApplicationCreateFromPath
. The problem is that this entire concept is deprecated. In recent macOS releases, there’s no way for an app from one team to ‘donate’ a keychain item to an app from another team, or the system, without triggering user authentication.

Can you explain more about the workflow you want to support? Presumably you’re grabbing the identity from the file and placing it in the keychain. What apps do you want to add to its ACL? Xcode?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I would like to setup identities and few generic passwords (Xcode-Token and Xcode-AlternateDSID) to the login keychain with allowed access for /usr/bin/codesign, /usr/bin/security and /usr/bin/productbuild (application list taken from fastlane). This terminal application designed to be called mostly on CI machines with initial credentials (.p12 files and source keychain with included SecItems) stored inside the private repository.


I see two already available alternatives:

1. Create SecAccess with nil trustedApplicationList to make default Restricted ACL available for any application. I would like to avoid such a case because of security concerns.

2. Call terminal app /usr/bin/security import with -T argument to pass required apps. While this solution will work, it still feels alien in the Swift macOS application. Another point is the influence of the same deprecation on security tool.

3. The weirdest solution (not guaranteed also, and not encouraged by Apple) to look for workaround based on Security opensource project. It's absolutely should be avoided in 99,9% of cases but still worth a point in the list.

Are you planning to distribute this as a binary? Or as buildable source code?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I suppose both. The project is going to be opensource repo available as a buildable SPM target. Also, I consider CocoaPods practice with precompiled tool to simplify workflow (e.g. swiftlint).

SecTrustedApplicationCreateFromPath replacement
 
 
Q