I have to comment that I'm not surprised at all that it's you, who provided answers and help :-) Yeah, I've noticed the keys are different, but I didn't know anything about the legacy format "1.1" (I mentioned I'm not very experienced with cryptography).In any case, thanks for clarification.

Thanks Quinn. However, your response yields some further question and I think the best way going forward is to explain what I'm actually trying to do. Let's say a user uses password protected SSH keys and ssh-agent for secure connection to remote servers. ssh-agent configuration file has a line: UseKeychain yes The first time ssh-agent establishes a connection using a certain key, it asks for a password for that key and if entered correctly, the password is saved in the keychain. Inspecting it in Keychain Access application reveals the password is saved in "iCloud" (iOS-style) keychain with account private_key_full_file_path and service OpenSSH. I'm actually trying to access that password. My application also makes secure connections, but I can't use ssh-agent, since the application is sandboxed. I ask user to select a private key file (thus gaining access to it through Powerbox and saving it in security scoped bookmark for further access), but then comes its password. I can ask for the password and optionally offer a possibility to save it in the (default, login) keychain and that's what I currently do. But I'd like to conveniently access the same password in the "iCloud" keychain, already saved by ssh-agent. Again inspecting it in Keychain Access, the password has one access group, com.apple.ssh.passphrases. Hence I wanted to add that keychain entitlement to my application, like: keykeychain-access-groups/key array stringcom.apple.ssh.passphrases/string /array I'm not even sure if that would work, but even before trying I realised adding keychain-access-groups entitlement requires adding a provisioning profile as well. I tried two profiles; the first one is meant for development only, created with a wildcard (*) for App ID, my Apple Development certificate and my registered M1 Mac as a target device. That profile (once downloaded) fails to install with error message "Provisioning profile does not allow this device." The other profile is for deployment, created with application bundle identifier (prefixed with my Team ID) for App ID, my Developer ID: Application certificate and again my M1 Mac as a target device. This profile installs successfully, but in its summary I can see something like: keykeychain-access-groups/key array stringMy_Team_ID.*/string /array This clearly indicates using that profile I won't be able to access a keychain item with access group com.apple.ssh.passphrases. So my question now is whether what I'm trying to do is possible at all or not. And if so, how to do it. Thanks,- Dragan

So in essence, what I'm trying to do isn't possible. I assumed that… Thanks for your answer.

@joehinkle11, I did solve it, but not using system APIs. I use: https://www.openssh.com/portable.html I actually created my own small library, aimed only to create those keys and stripped away all other unnecessary code, trying to keep its footprint as small as possible.

@Quinn You mean Console app? Or the Console pane in Xcode? Console.app. Since I see them there as well and I'd like my application to be as silent as possible.

Thanks Quinn “The Eskimo!” 👍🏻 • Adopt SMAppService. This is clearly the best option (-: I can't I still have to support macOS 10.13+ …the short-term solution is to add AssociatedBundleIdentifiers to your launchd property list. See the launchd.plist man page for details. This is what I needed, it worked like a charm, thanks a lot!! Now that I know the search keyword (AssociatedBundleIdentifiers), I see the solution already being discussed here. Unfortunately, changes in launchd.plist man page skipped my attention. Thanks again, -- Dragan

As someone has notified me in the meanwhile, this is the consequence of the default value of property clipsToBounds of NSView being changed from 'YEStoNO` in Sonoma SDK. -- Dragan

Hello, Just pinging to ask what has happened to this one? I expected this to be resolved before the official of Sequoia (despite seeing it not being solved in numerous betas, I still hoped the official release would change that), but it isn't. I don't see any changes in this regard in macOS 15.1 Developer Beta either. Will this be fixed? Is there any feedback / bug report already filed? Do I need to "waste" my DTS ticket for this (although I don't see how it would change anything)? Quinn “The Eskimo!”, can we please have an update on this?

Hello, Just pinging to ask what has happened to this one? I expected this to be resolved before the official of Sequoia (despite seeing it not being solved in numerous betas, I still hoped the official release would change that), but it isn't. I don't see any changes in this regard in macOS 15.1 Developer Beta either. Will this be fixed? Is there any feedback / bug report already filed? Do I need to "waste" my DTS ticket for this (although I don't see how it would change anything)? Quinn “The Eskimo!”, can we please have an update on this?

Kevin, It may be I don't understand things very well and terrible state of ExtensionKit documentation doesn't help my case, but I don't think your proposal will work. I actually tried it and it didn't work, but like said, I'm not sure if I did everything right. First of all, EXAppExtensionBrowserViewController is part of ExtensionKit, wheres FinderSync extensions have nothing to do (at least on the highest level) with that framework. Secondly, as I understand it (and I'm not sure about it and again, terrible state of documentation doesn't help), EXAppExtensionBrowserViewController is supposed to be used to list and enable/disable extensions hosted/embedded in OTHER applications, which has NSExtensionPointIdentifier matching custom extension points declared by OUR application. But here, we actually have problem with OUR application, which is a host/container of FinderSync extension, with NSExtensionPointIdentifier = com.apple.FinderSync. It is the responsibility of some OTHER application (defining com.apple.FinderSync extension point) to provide user interface to list and enable/disable FinderSync extensions. And that has being done by System Preferences / System Settings application, until Sequoia. What I did: I left my application, hosting a FinderSync extension, just as it is, but tried to show EXAppExtensionBrowserViewController. I got an "empty" window, just saying "Select extensions for customizing FIleUtils:" (FileUtils is my application name), without any following list of extensions (and applications hosting them). I even tried something crazy, trying to declare my "custom" extension point com.apple.FinderSync in the .appextensionpoint plist file (copied during build phase into ExtensionKit Extensions destination) and then show EXAppExtensionBrowserViewController. The result was the same; "empty" window, just saying "Select extensions for customizing FIleUtils:", without any following list. And we actually need a window, which would say Select extensions for customizing Finder:, since that's the application (declaring extension points) which our FinderSync extension (bundled into our application) wants to customize. And for that purpose we have +[FIFinderSyncController showExtensionManagementInterface], which worked fine before Sequoia. Please let me know if I should do something similar to enable FinderSync extension using EXAppExtensionBrowserViewController. But as far as I understand how ExtensionKit works, that's not the way to go.

Quinn, Yeah, talking to him as you speak… Perhaps there's a way to lock this thread, so that people don't get confused and search for solutions on various places. Thanks! -- Dragan

Anyway, I've filed a bug/request/whatever and this is the feedback reference number: FB15249290

I'm looking any other way to enable the extension but I haven't found any yet and I'm not optimistic that I'll find one. One can use /usr/bin/pluginkit. As part of that bug report, I'd recommend including the specifics of the product you're using it in, not simply the fact that it's broken. I believe I gave correct and sufficient description of the problem here. There's nothing special about the "product using it", it's just an application hosting a FinderSync extension and we need a way to manage those extensions, like any others.

… it's also true that file sync use case FinderSync Extensions were designed address has been largely replaced by the newer (and superior) replicated file provider architecture. I'd like to comment on this. It's true that current documentation says: Use this framework when you need to synchronize the contents of a local folder with a remote data source. Then provide visual feedback to the Finder… However, the initial documentation was't that strict: Finder Sync supports apps that synchronize the contents of a local folder with a remote data source. It improves user experience by providing immediate visual feedback directly in the Finder The word "supports" doesn't imply a limitation (English is not my first language, so I may be wrong). I believe many other developers understood it the same as me, especially considering the fact that Finder Sync extensions provide a way to add custom menu items to Finder's contextual menu. I think most developers saw it as a sort of continuation of old CMPlugin API from MacOS (yes, the capital 'M') 8/9 days, which was available until Mac OS 10.6 Snow Leopard. It's seen as a way to extend Finder's capabilities, by executing custom operations (not limited to "synchronize the contents of a local folder with a remote data source") on files selected in Finder. I think I know about 50 - 60 applications embedding Finder Sync extensions at the moment, and only a dozen of them actually "synchronize the contents of a local folder with a remote data source", mostly coming from huge and well known cloud providers (Dropbox, Google, Microsoft…). All others, mostly coming from independent Mac developers, offer some custom operations of files selected in Finder, nothing related to any sort of syncing. I believe MR_Noodle's case is the similar one, "outside of its recommended use case". Taking the above into consideration, I think it'd be a huge mistake for Apple to discontinue and deprecate Finder Sync extensions without providing functionally equivalent replacement. That would break a lot of third party Mac software and render those applications completely useless. I say that because I'm starting to think that's actually going to happen. First we had "Finder Extensions" settings section missing in System Settings on Ventura (it was there in the early versions, but disappeared in the latter ones), leaving "Added Extensions" as the only place to manage Finder Sync extensions on Ventura and later. And now "Added Extensions" is missing as well. Similar actions on Apple's part in the past usually meant deprecation of technology and I'm afraid this is such case, but I really hope it is not! I'd appreciate if this comment is somehow passed to people in charge of future development directions of macOS and that they will seriously consider what was said here. Thanks a lot!

In the meanwhile, until Apple hopefully fix the issue and put settings section back into System Settings application, if you don't want to kick-off terminal and use pluginkit, you can try FinderSyncer (https://zigz.ag/FinderSyncer - no inline link, since "This domain "https://zigz.ag" is not a permitted domain on this forums" 😐)