User Profile

As long time Mail plugin developer (11 years) I really welcome the addition of extensions for Mail. Unfortunately for now the feature set is very minimal and will only help us to implement a minimal viable version of our product if we switch to it. Is the current API set in stone for macOS Monterey or does it make sense to send feature requests? If so, where it the best place to post them? Here or via Radar? Thanks!

For a few days now, notarytool is crashing whenever I'm running one of my Jenkins jobs where notarytool is called from a shell script. Based on the debug log, the crash appears round at the time that the upload of the binary to be notarized is attempted. When a runloop should be started to run the upload via an async http request: Debug [TASKMANAGER] Starting Task Manager loop to wait for asynchronous HTTP calls. The specific job setup looks like this: Jenkins Job › Run shell script phase › Shell script › Second shell script › notarytool call. Running the notarytool directly from Terminal works and completes as expected. Crashlog Snippet: Path: /Applications/Xcode-14.2.app/Contents/Developer/usr/bin/notarytool Identifier: notarytool Version: ??? Code Type: X86-64 (Native) Parent Process: launchd [1] Responsible: java [428] OS Version: macOS 12.6.2 (21G320) Crashed Thread: 1 Dispatch queue: com.apple.NSURLSession-work Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [18889] Application Specific Signatures: API Misuse Thread 1 Crashed:: Dispatch queue: com.apple.NSURLSession-work 0 libxpc.dylib 0x7ff81aa2720e _xpc_api_misuse + 117 1 libxpc.dylib 0x7ff81aa128bb xpc_connection_set_target_uid + 193 2 AppSSOCore 0x7ff8264facaa -[SOServiceConnection _connectToService] + 533 3 AppSSOCore 0x7ff8264faa6f -[SOServiceConnection initWithQueue:] + 102 4 AppSSOCore 0x7ff8264fa98a -[SOClient init] + 122 5 AppSSOCore 0x7ff8264fa855 -[SOConfigurationClient init] + 180 6 AppSSOCore 0x7ff8264fa78c __38+[SOConfigurationClient defaultClient]_block_invoke + 16 7 libdispatch.dylib 0x7ff81ab1c317 _dispatch_client_callout + 8 8 libdispatch.dylib 0x7ff81ab1d4fa _dispatch_once_callout + 20 9 AppSSOCore 0x7ff8264fa77a +[SOConfigurationClient defaultClient] + 117 10 AppSSOCore 0x7ff8264fa6af +[SOAuthorizationCore _canPerformAuthorizationWithURL:responseCode:callerBundleIdentifier:useInternalExtensions:] + 130 11 AppSSOCore 0x7ff8264f9df0 appSSO_willHandle + 64 Back in January the exact same setup was still working. Same macOS version. Xcode version might have been different. Would really appreciate some help since for now re-implementing notarytool appears to be the only solution.

In the session there's no mention how the RFC822 data is to be parsed. macOS has long shipped the MailCore framework, which exposes important classes to parse RFC822 messages. Is this framework available for Mail Extensions or is every developer required to bring their own MIME framework?

SummaryIf a user enters the wrong password, when they are asked for their macOS user credentials to access the password of a keychain item, and press "Do not allow" when asked again, the following happens:programmatic access to the keychain item's password using SecItemCopyMatching consistently fails with error OSStatus -25293, yet the user is never prompted to enter their macOS credentialsprogrammatic access to the password of any keychain item of the same keychain fails with error -25293the user is not asked for their credentials again until they manually lock and unlock the login keychain (or any custom keychain the keychain item belonged to) in Keychain Access.app (or perform an action which locks and unlocks the keychain, like log out or restart of macOS)WARNING: After trying to reproduce this problem, iMessage will no longer work and no new keychain items can be added until the login keychain is locked/unlocked manuallyA custom script using the Security.framework keychain API's is available, but for most basic steps to reproduce the "security" command line utility is used.While I really don't think this is expected behavior, I'd be interested to learn more.Steps to Reproduce:1.) Create a login keychain item for the testsecurity add-generic-password -l "Keychain Bug Test Item" -a "AccessToKeychainItemsPasswordIsLostRdar" -s "keychain-bug" -T "" -w "supersecurepassword"2.) Try to access the test keychain item.security find-generic-password -a "AccessToKeychainItemsPasswordIsLostRdar" -wWhen presented with the authentication dialog, enter your macOS credentials. -> the password "supersecurepassword" is displayed in Terminal3.) Try to access the test keychain item, but fail on purposesecurity find-generic-password -a "AccessToKeychainItemsPasswordIsLostRdar" -wThis time, when presented with the authentication dialog, make sure to enter the wrong credentials and press "Allow". After being asked for your password a second time, press "Don't allow"3.) Try to access the test keychain item againsecurity find-generic-password -a "AccessToKeychainItemsPasswordIsLostRdar" -wYou will notice that the command exits without displaying the password and without ever presenting an authentication dialog. Test if you are able to send a message in iMessage. That will no longer work.In my tests, even keychain item's which "Allow any application to access this item without warning" were no longer able to retrieve the passwordExpected Results:As before entering the wrong credentials, the user should simply be presented with an authentication dialog again. At the moment, they are not informed of any problem, yet won't be able for example in iMessage to send messages. The bug will show different symptoms in different applications, depending what keychain access is used for.Actual Results:The user is never prompted for entering their credentials again. Applications fail to work properly in different way.Version/Build:macOS 10.14.3 (18D109), macOS 10.14.4