User Profile

I'm running into the same issue. Maybe @eskimo can help, as this can potentially break a lot of automations. There were talks about softwareupdate being deprecated, but not much in the direction of offering an alternative to softwareupdate.

Thank you for the response, Etresoft. In all honesty, I did not see the the third line. I used to use the verification as references on the official Apple webpage for debugging notarization issue. - https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735, which returns only the first two lines: codesign -vvv --deep --strict <my_lib.dylib> <my_lib.dylib>: valid on disk <my_lib.dylib>: satisfies its Designated Requirement But then saw the post from eskimo and though to give that at try, as well, and it seemed to return the same thing (which I now see it does not). The whole build process is fully automated and only this particular build has problems (without any error in the notarization plists returned by the various tools used in the process). The dylibs and exe file is zipped and sent to the notarization tool. In any case, I will use the verification suggested by eskimo in order to at least get a hint if the notarization may have failed and also do the smoke test as you suggested. However, it's a bit disappointing to see that automation is not supported for the verification and, more so, that there is no indication regarding this on the official Apple documentation

The parent is waiting for the children using waitid. Here is how we do it:do{ // read from pipe until exit/timeout is reached}while( ( waitid( P_PID, childPid, &amp;sigInfo, WEXITED | WSTOPPED | WNOHANG ) == 0)&amp;&amp; (sigInfo.si_pid == 0)&amp;&amp; (usleep( 1000 ) == 0)&amp;&amp; (waitTimeMS++ &lt;= max_timeout_ms) ); // this is the timeout check, but in our case it is not usedWe will enhance, in the future, the signature verification check to use the Objective C APIs, but this does not seem to be the root cause for our issue.The zombie process is not a codesign specific issue and is reproducing also when calling other processes, like 'pkgutil', 'spctl', 'sysctl', 'date', 'id' and others. I mentioned 'codesign' as an example because is the most used process and the majority of the zombie processes are coming from it.Is the waitid approach a good one? Also, do you have any idea on what could be the root cause or do you have any guidance that will help us fix the issue?In the meantime, we are working on implementing some of the suggestions.Thank you!

@rnikander, do you still see the issue?I noticed a similar problem, and reported it in the Core OS section of the forums: https://forums.developer.apple.com/message/423193#423193

Thank you for your reply, @eskimo.Please find the answers to the questions below.&gt; Are you seeing this on 10.14.6? What about 10.15 beta?Yes, this issue is only seen with macOS Catalina (10.15 - all beta versions)&gt; How are you launching your “terminal application”?There are three ways by which I tried to run the application:Double-clicking on the application. This will throw out the error pop-up mentioned in the initial message - "&lt;my_app_name&gt; can't be opened because the identity of the developer cannot be confirmed".Right click on the application, then select "Open" from the pop-up which will be shown. This will actually open the terminal and run the application, and will actually work as expectedFrom a terminal window, by using "./diagnose". This will produce a similar result as #1, with the expection that the pop-up shown will have the option to "Move to Trash".The use for this application in itself is more based on option #3. Our customers will embed this application in their product, and when there is a need to run a diagnostic on the device, will simply run automically this app.&gt; How is it packaged? And how does it reference these libraries?It is not packaged in any way. The tool is provided as a zip archive, that contains the command line tool (diagnose), as well as 5 dylibs.The diagnose tool will explicitly link to one of the 5 dylibs and, then, this dylib will explicitly link to the other 4. The loading structure would look similar to the following:diagnose (dlopen libapi.dylib, using an absolute path)|-- libapi.dylib (dlopen lib1.dylib, lib2.dylib, etc., using an absolute path) | -- lib1.dylib -- lib2.dylib -- lib3.dylib -- lib4.dylibAll binaries (diganose + libs) are signed using the same Apple certificate, and then sent to notarization (which is successful), in a zip package that contains all of them.One other thing to mention, because I don't want to create any confusion regarding to the type of the application: the diagnose is a simple C++ command line app, created and compiled with Xcode 9.x, then signed with Xcode 10, in order to enable runtime hardening. The Xcode 9.x is required for compiling becuase it still offers the option to bundle the 32-bit version of the app, that is required by some of the customers.

Thank you @eskimo, for the quick answer.Are there any general accepted solutions in this case? Maybe restarting the process after the update process?