Post not yet marked as solved
Hi Quinn,
We implemented your suggestions and got an extremely useful log of the specific calls that are failing and returning an error.
Our code is terminating as we fail to write some critical information into a file that is required by our code. We're looking into whether its a bug on our side or there are some change we have to implement.
Thanks.
Post not yet marked as solved
Thanks Quinn. Will proceed and let you know what we find.
Post not yet marked as solved
Hi Quinn,
There is no crash report whatsoever. We know that the FBA is launched as we see it in the Activity Monitor and after a few seconds or so its terminated or quit (?).
One work-around we've asked our users to do is to add the FBA as a login item (so its launched automatically). And this work-around works but its getting difficult to tell users to do this as this odd behavior never existed before with macOS.
Post not yet marked as solved
Hi Quinn,
Absolutely yet. We use productbuild and pkgbuild to make our installer.
Post not yet marked as solved
Hi Quinn,That would be outside the Documents folder. Someone can for example obtain/reference a file from a mounted network server disk or choose to specify files be saved to a location outside the Documents folder (Desktop for example). Because our helper app is outside of the plug-in scope (its not a child process; though making it a child process may actually be something we could consider), its launched via launchApplication). Thank you for the link to the Advances in macOS security.
Post not yet marked as solved
Hi Quinn,App Sanbox is not enabled and there are no entitlements that show up. Are we supposed to use the App Sandbox entitlement? There is no open/save dialog our external helper app presents (its there so invoke some libraries and act as a bridge). Because the app is an external process (outside of the Photoshop plug-in) it's in it own process space (this is to protect Photoshop in case our app an any components it utilizes crashes). We don't think entitlements carry across the process boundaries (Photoshop's entitlements are propogated to the plug-ins but for an external helper app that is not part of the plug-in itself).
Post not yet marked as solved
Hi Quinn,Again thank you for your insight. Its just a legacy system thats carried forward (the dylib/resource issue) in a straight forward fashion. We expect to move these to a framework in the future (we have a lot of legacy code that we've migrated forward over the years and bits remain). This probably is one of the last pieces of the migration puzzle we have for the future.Also, we were able to notarize/run our latest builds without a hitch (so everything seems to be in place) and in testing these builds out we've understood that when our "external app" which is a helper to the Photoshop plug-in starts read/writing files outside of the Documents folder, the macOS 10.15 security framework kicks in asking whether to grant read/write access across the network/certain directories etc. We presume this is an entitlement issue during codesigning? Is there a univeral file read/write entitlement so that we can stop this? Or is this part of how things are going to work?
Post not yet marked as solved
Hi Quinn,Thanks for your response. After I wrote the above we started testing with some of our newer builds (where we had migrated code out of fsref and some other older API's that are marked deprecated) and the crash is gone. So maybe the fsref and migrating out of older SDK (less than 10.9) helped?We have one final question. Because our components are mainly dylibs, bundles etc, we have resources that reside outside the dylibs and we store these as zipped data (not code but data fork .rsrc). As these zip's can't be codesigned, we presume it wont cause any kind of notarization issue? Its just data that is loaded by the dylibs for usage.
Post not yet marked as solved
HI Quinn,Thank you for explaining in detail and yes this is all helpful. Now we have an additional question.Our Photoshop plug-in launches an external backround application that creates files and then passes these files back to the host Photoshop plug-in; which then passes it back to Phostoshop We've realized that this is causing a crash right now. Is this because of some kind of code-signing/security scope? Are we missing something?
