For some time now, one application I work on with Xamarin for Mac has bundled the WKHTMLTOPDF application for production of PDF files from HTML. Until recently - a couple of weeks ago - this worked fine, and there wasn't any need to code-sign WKHTMLTOPDF separately. However, recently Apple must have tightened their requirements, and without WKHTMLTOPDF being code-signed, the resultant installer package for the application would not be notarized. To address this I've run the following command:
codesign -s "Developer ID Application: Company Name (CompanySigningID)" --timestamp --entitlements entitlements.plist -o runtime wkhtmltopdf
... and with this the overall application passes notarization. The 'entitlements' are the same as the ones we've used for the main application.
However, after code-signing, WKHTMLTOPDF doesn't run properly... examining standard out / error out dumps, it fails when it starts to load the HTML file (which is a file produced and stored on the local file system), with an exit code of 138 (which I suspect is the exit code from the embedded / patched QT functionality within WKHTMLTOPDF; I haven't been able to track down exactly what this exit code means, though, just yet). My suspicion is that, with the code-signing, the running of WKHTMLTOPDF (via Process.Start) is requiring file system, but there is no provision for prompting the user to allow this access, and it just fails.
Without WKHTMLTOPDF being code-signed, it runs and functions correctly, however then the notarization fails, so this is a non-starter. I am at a bit of a loss how to progress from here, or even how to gather extra information that might help in narrowing down the issue. Does anyone have any tips or information that might be of assistance, please?