Runtime troubles

[William]

I'm having trouble with FMPA 18.0.3.317 creating a runtime.  Even with the simplest file, I create it and when it runs it immediately crashes with the following in the crash report:

Exception Type:        EXC_CRASH (Code Signature Invalid)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 0x1

I did the exact same thing with FMPA 17.0.6.600 and it worked fine.

Any suggestions as to what's going on here and how I might fix it?

Thanks!

Edited November 1, 2019 by William

[FileMaker Developer]

Look at the Runtime app, and Show Package Contents. Remove _CodeSignature folder. Close the folder and re-lauch the runtime app. It should work.

I only noticed this after comparing the Runtime apps of older FileMaker Pro apps with the latest FileMaker Pro 18 runtime apps. Older runtime apps DO NOT contain this _CodeSignature folder. And those older Runtime apps do run on macOS High Sierra (and presumably Catalina). So removing the offending folder from the latest runtime app actually makes it work.

[AndreasvanHaren]

I have the same problem and removing the folder fixes it, but how do you prevent that folder from being created?

[stefangs]

I have followed these instructions and the runtime worked. Now I created a zip and uploaded to my server. I then download the zip from the server. Both folders have the exact same number of bytes.

But the local copy works and the downloaded copy does not. It says, the app is damaged and should be moved to the trash. What the hell is going on?? I tried both zipping the folder itself and creating a .dmg around it before zipping. Makes no difference.

 

Help please

[stefangs]

FileMaker won't even answer my question about runtimes, because the feature is deprecated. They still sold it to me, though and it is something I use. As far as I'm concerned, the feature isn't deprecated, it just doesn't work. Watch for yourself and let me know if you know how to fix that, please!

https://youtu.be/3_5O4-e7IKY

[Wim Decorte]

If they have used those exact words (we won't help you because it is deprecated) then escalate the support ticket.  Deprecated means "will be removed in a future version", which happened in 19.  You are entitled to support.

[Teilo]

On 5/18/2020 at 6:17 PM, stefangs said:

I have followed these instructions and the runtime worked. Now I created a zip and uploaded to my server. I then download the zip from the server. Both folders have the exact same number of bytes.

But the local copy works and the downloaded copy does not. It says, the app is damaged and should be moved to the trash. What the hell is going on?? I tried both zipping the folder itself and creating a .dmg around it before zipping. Makes no difference.

 

Help please

None of this is the fault of Filemaker. It's Apple's new code signing and notarization requirements.

As to why this is happening: It's because macOS quarantines any unsigned files it sees, and you need to de-quarantine them before you can run them. They get quarantined no matter how the apps make it onto your system: from a network drive, USB drive, ZIP file, download, it doesn't matter. The quarantining is automatic. If you have properly code-signed apps, macOS will automatically dequarantine them.

The fix for this is very simple. De-quarantine the app. The easiest way is to right-click it, choose Open, then click Open. The app should run fine.

The reason this is only an issue in 18, is because 17 and older did not sign runtimes.

As to your crashing problem, the problem is that apps that have signatures past a certain date now require notarization. There is no way to notarize a runtime app. And so what happens is that when Catalina sees a signed app past a certain date, with no notarization, the app crashes.

To fix this, it is often not enough to delete the Code Signature folder. You may also need to remove the code signing headers from the application binary itself. This can only be done with special tooling, from Terminal. Once you do this, the resulting application bundle will run as an entirely unsigned app. You still need to de-quarantine it, though, after copying it to a new system. There's no way around that.

Edited May 21, 2020 by Teilo

[stefangs]

18 minutes ago, Teilo said:

None of this is the fault of Filemaker. It's Apple's new code signing and notarization requirements.

As to why this is happening: It's because macOS quarantines any unsigned files it sees, and you need to de-quarantine them before you can run them. They get quarantined no matter how the apps make it onto your system: from a network drive, USB drive, ZIP file, download, it doesn't matter. The quarantining is automatic. If you have properly code-signed apps, macOS will automatically dequarantine them.

The fix for this is very simple. De-quarantine the app. The easiest way is to right-click it, choose Open, then click Open. The app should run fine.

The reason this is only an issue in 18, is because 17 and older did not sign runtimes.

As to your crashing problem, the problem is that apps that have signatures past a certain date now require notarization. There is no way to notarize a runtime app. And so what happens is that when Catalina sees a signed app past a certain date, with no notarization, the app crashes.

To fix this, it is often not enough to delete the Code Signature folder. You may also need to remove the code signing headers from the application binary itself. This can only be done with special tooling, from Terminal. Once you do this, the resulting application bundle will run as an entirely unsigned app. You still need to de-quarantine it, though, after copying it to a new system. There's no way around that.

Very interesting read!

Of course, I immediately tried your suggestion of opening the app the a right-click. But the same error message appeared. Now I want a copy of Fm17.

What's the tooling magic in Terminal you talked about. I guess eventually I will have to give up on this problem, but I'm not there just yet.

4 hours ago, Wim Decorte said:

If they have used those exact words (we won't help you because it is deprecated) then escalate the support ticket.  Deprecated means "will be removed in a future version", which happened in 19.  You are entitled to support.

Here's an excerpt from Claris support mail:

Quote

We haven't supported run times solutions in some time, they have been deprecated out of newer versions. However like I said if you want to speak with other developers that may be able to see more of the insight on how you built It they may be able to provide some answers. You can do this on our community with the clone I mentioned by making an account and posing a question with it attached (Commuting.filemaker.com or community.claris.com). I cannot open this file either, I am running OS X 10.13.6 and it crashes with repot. 

Kind of like the verbose version of 'Good luck'

[stefangs]

15 hours ago, Wim Decorte said:

If they have used those exact words (we won't help you because it is deprecated) then escalate the support ticket.  Deprecated means "will be removed in a future version", which happened in 19.  You are entitled to support.

How do I escalate a ticket? I thought this is something only support can do.

[Wim Decorte]

You call them and tell them to escalate the ticket; don't take 'no' for an answer; you're a customer.  Forums like this one and the official community one are not official Claris support channels.  We can help with our experience but if you need/want official support you have to be on the phone with them until you get what you are after.

The only other place where you can post an official issue is here: https://community.claris.com/en/s/topic/0TO0H000008OQOGWA4/report-a-product-issue

But that is not more efficient than just calling them and not letting go until it is escalated.

[stefangs]

Thanks Wim, I'll pester them and see if they help me sort it out.