Post

Replies

Boosts

Views

Activity

macOS XPC: SecItemAdd throws an error [-25308 errSecInteractionNotAllowed]
When I create an XPC service And that XPC service runs a command line tool via NSTask API And that command line tool tries to use SecItemAdd to store an item in Keychain Then I receive -25308 error which is errSecInteractionNotAllowed in Keychain API reference However, when there's no XPC service between Main app (UI) and command line tool, then SecItemAdd works as expected (i.e. NSTask is run from the app that user has launched comparing to XPC service that was launched with launchd) Code is available here: https://github.com/art-divin/XcodeUpdates/tree/feature/issue-6 While running, one can notice that there's an error when the app tries to write an item to Keychain. TSI #757702091
1
0
885
Jan ’21
FileHandle's readabilityHandler not called when detached from debugger
Hello, I am facing an issue with NSTask (Process), NSPipe (Pipe) and NSFileHandle (FileHandle). I have an app that executes a child process (command line utility) and gets its output via Pipe instances set as standardI/O of Process instance. I can observe two logic flows: Once the child process exits, -[Process readabilityHandler] gets called where I gather the $0.availableData. Once the child process generates output (i.e. print() is executed by the child process), -[Process readabilityHandler] also gets called which makes sense. This is the case when exit() is not called by the child process (i.e. continuous execution). However, when LLDB is detached, #2 is false, i.e. -[Process readabilityHandler] is not called. Wrong behaviour also happens if I don't rely on readabilityHandler, but instead use Notification to receive changes in data availability. In such case, notification gets called continuously with empty data (even though child process does generate the output). If I don't create Pipe instance for standardI/O of the Process, then readabilityHandler does get called, but with an empty data continuously. I have created a DTS #756462540, since this doesn't make any sense. Prerequisites* app is not sandboxed Big Sur 11.0.1 (20B29) Xcode 12.3 (12C33)
5
0
3k
Dec ’20