XPC_ERROR_CONNECTION_INVALID from launchservice

Dear Apple
I am developing a dotnet core software and now I am trying to sign and distribute properly our application. The deployment is semi-automatic I am using a dotnet core software to make the signing and the notarization of the app, which is calling the appropriate tool for example codesign.
After I created the final dmg I mount it copy the app to the Application, start it, then after the verification, it exits with a failure which is the following:


Process:               wassabee [9757]
Path:                  /Applications/Wasabi Wallet.app/Contents/MacOS/wassabee
Identifier:            wassabee
Version:               1.1.10 (1.1.10)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           wassabee [9757]
User ID:               502


Date/Time:             2020-01-13 10:14:40.191 +0100
OS Version:            Mac OS X 10.15.2 (19C57)
Report Version:        12
Anonymous UUID:        C79F51FE-2AE6-9768-EC91-1F5E7F1D04DC


Sleep/Wake UUID:       B37B57B0-B981-4F39-9704-C03CE8F4DFF2


Time Awake Since Boot: 24000 seconds
Time Since Wake:       3000 seconds


System Integrity Protection: enabled


Crashed Thread:        0  Dispatch queue: com.apple.main-thread


Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY


Application Specific Information:
abort() called
rdar://problem/28724618 Couldn't create connection object
 Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.
XPC_ERROR_CONNECTION_INVALID from launchservice
_RegisterApplication(), unable to get application ASN from launchservicesd, and this application requires an ASN, so aborting.  error=#-1.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        0x00007fff6993e7fa __pthread_kill + 10
1   libsystem_pthread.dylib        0x00007fff69a00bc1 pthread_kill + 432
2   libsystem_c.dylib              0x00007fff698c5a1c abort + 120


So IMO there is something with the entitlements used during the signing.


I use this entitlements file on non-executables:

https://github.com/zkSNACKs/WalletWasabi/blob/afd0768c6509ca54d4a786ac5105ffe1e6731785/WalletWasabi.Packager/Content/Osx/entitlements.plist

I use this on executables (3 files)

https://github.com/zkSNACKs/WalletWasabi/blob/afd0768c6509ca54d4a786ac5105ffe1e6731785/WalletWasabi.Packager/Content/Osx/entitlements_sandbox.plist


There might be some unnecessary tags in it, that is my effort to fix the error.


There are more details here about the issue:
https://github.com/zkSNACKs/WalletWasabi/pull/2946


I am using: Developer ID Application: zkSNACKs Ltd. (L233B2JQ68) to sign everything.


Thank you for your help.


Best regards,

David

Replies

By the way I uploaded the failing dmg here, just in case: https://github.com/molnard/WalletWasabi/releases/tag/macsign

Still a question! Anyone any idea?

I use this entitlements file on non-executables:

Just FYI, the entitlements for a process are set based on the entitlements of the main executable. Thus, these entitlements are ignored. Their presence is weird, but essentially benign.

I use this on executables (3 files)

Well, that’s definitely wrong. If you want the process to inherit its sandbox from its parent, you must have

com.apple.security.app-sandbox
and
com.apple.security.inherit
and no others. If you don’t want sandbox inheritance, you must not have
com.apple.security.inherit
. Having
com.apple.security.inherit
and a whole bunch of other entitlements is both incorrect and likely to cause problems.

By the way I uploaded the failing dmg here

I downloaded that and took a look at your the entitlements of your main app:

% codesign -d --entitlements :- /Volumes/Wallet\ Wasabi/Wasabi\ Wallet.app 
…
<dict>
    …
    <key>com.apple.security.inherit</key>
    <true/>
</dict>
</plist>

You definitely need to get rid of

com.apple.security.inherit
. The main app has no ‘parent’ sandbox that it could inherit from.

Beyond that, I’m very concerned by your packaging. Consider this:

% ls -l "/Volumes/Wallet Wasabi/Wasabi Wallet.app/Contents/MacOS/" 
total 278808
-rw-r--r--@ … AvalonStudio.Shell.Extensibility.dll
-rw-r--r--@ … AvalonStudio.Shell.dll
-rw-r--r--@ … AvalonStudio.Utils.dll
-rw-r--r--@ … Avalonia.Animation.dll
…

The

Contents/MacOS
directory is meant to contain code, and it’s full of all these DLLs. Now, those are actually code, but they’re not in Mach-O format and thus can’t be signed in the usual way. Consider this:
% ls -l@ "…/AvalonStudio.Shell.Extensibility.dll"
-rw-r--r--@ 1 quinn  staff  137216 13 Dec 14:06 …/AvalonStudio.Shell.Extensibility.dll
    com.apple.cs.CodeDirectory           216 
    com.apple.cs.CodeEntitlements        802 
    com.apple.cs.CodeRequirements        192 
    com.apple.cs.CodeRequirements-1      288 
    com.apple.cs.CodeSignature          9058

These extended attributes are present because these files are being signed as code but they can’t actually hold a code signature. As a result, the system dumps the code signature in extended attributes. This is very brittle.

Finally, yesterday I posted Signing a Mac Product For Distribution, which you’ll probably find useful.

Share and Enjoy

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

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

Dear Eskimo,


Thank you for your detailed answer. From there I was able to make it work.

https://github.com/molnard/WalletWasabi/releases/download/v1.1.10.2-200204/Wasabi-1.1.10.2.dmg


However I could not restructure the dotnet core app folders as you described.
- I created symlinks with ln -s for every file but when I ran the executable I got missing file errors, dispite of that the symlink was there and working.

- I also tried exactly the same algorithm but with hardlinks (ln) then the application worked. Do you recommend to duplicate the files in this way? So for example put the dylibs into Framework directory and create a hardlink to it from MacOs directory? Now it is working without restructuring.
Dmg creation: is there a way to have the good old internet-enable feature with hdiutil?


One more thing that I could not solve is that now I got the message "App was downloaded from github... Open?". I press the Open button and for the first time nothing happens. On the second attempt the application just starts.


Thank you in advance,

Dave

I created symlinks with

ln -s
for every file but when I ran the executable I got missing file errors, dispite of that the symlink was there and working.

My experience is that macOS is good about following symlinks in this scenario. A while back I posted a concrete example of how to make this work on this thread. I’m not sure why it’s not working in your setup.

I also tried exactly the same algorithm but with hardlinks (ln) then the application worked. Do you recommend to duplicate the files in this way?

Hard links are not duplicates, but they can very easily turn into duplicates depending on the technique you use to archive and unarchive your app. I generally recommend that you avoid this.

is there a way to have the good old Internet-enable feature with

hdiutil
?

I don’t understand this. Please clarify why you mean by “Internet-enable feature”.

One more thing that I could not solve is that now I got the message "App was downloaded from github... Open?". I press the Open button and for the first time nothing happens. On the second attempt the application just starts.

That is very strange. I’ve not seen anything like that before. If you want to get to the bottom of this, I recommend you open a DTS tech support incident so that I can allocate the time needed to investigate.

Share and Enjoy

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

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

Thank you for your answer.

I am jumping back to my original problem, unfortunately. It turned out that I made a typo and sandbox was not added - that why the error was solved (inheritance removed). https://github.com/zkSNACKs/WalletWasabi/blob/de503b6d2fee30a0cb849e389d0bdae5651802b0/WalletWasabi.Packager/Content/Osx/entitlements.plist


  1. However, our current dmg package and app inside almost works as we would like to. There is only one message from the Gatekeeper: "The application was downloaded from the internet..." it looks like this: https://imgur.com/a/RDL5vfZ
    As far as I know, this Pop-up is normal and cannot be avoided - gatekeeper will always warn me that it is from the internet despite that it is properly signed and notarized. With our previous basic packager, we did not have the Open button so users had to go to system/security.
    You can see it for yourself by install and start this: https://github.com/molnard/WalletWasabi/releases/download/v1.1.10.2-200204/Wasabi-1.1.10.2.dmg
  2. After pressing the Open button for the first time then app closed immediately. I have to click on the app again. After that, it will work without an issue. If you dragndrop the app from the dmg then again - it won't start for the first time.
  3. Until now I opened the dmg dragndrop the app and close the dmg window. There was no new drive on the Desktop. Now there is the mounted image on the desktop until unmounting it - anyway it is not priority.
  4. Symlinks are not working with dotnet-core app. So currently I see no way to make the folders OK.
  5. With sandbox I am still getting the error mentioned above. There is a subcomponent that is trying to do things with launchservicesd. Can it be the problem? Shall we start to investigate there? Shall I send the report to DTS that was generated by the app?


Best regards,

David

As far as I know, this Pop-up is normal and cannot be avoided - gatekeeper will always warn me that it is from the internet despite that it is properly signed and notarized.

I can’t, alas, read the language in that alert but, yes, Gatekeeper will always present an alert if the app is quarantined. If the alert has a button that allows you to continue, that means Gatekeeper is happy. If not, you won’t be able to continue (you’ll either have an OK button that simply acknowledges the inability to continue or the Move to Trash and Cancel pair).

After pressing the Open button for the first time then app closed immediately.

See my answer above.

Symlinks are not working with dotnet-core app.

As I demonstrated above, symlinks should work just fine on the macOS side of things. It’s possible that your third-party runtime is not following them, although that would definitely be weird. It’s more likely that you didn’t set things up properly.

Either way, this is something you’ll have to pursue at you end, possibly in concert with your third-party runtime vendor. If you uncover evidence that Apple’s system software is doing the wrong thing with symlinks, let me know.

With sandbox I am still getting the error mentioned above.

I’m not entirely sure which error you’re referring to here.

Shall I send the report to DTS … ?

Yes. That’ll allow me to allocate more time to look at your various issues.

Share and Enjoy

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

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

Dear Eskimo,


Before DTS I will investigate on our side. We might have a dependency that is trying to do something with launchservicesd.


Thank you for your help! I will get back here after that.


Best regards,

David