Subject: Igor Pro on macOS 10.15 (Catalina)
In-Reply-To: <CAAbtOZfj3AFJ1pVcBNJtCjqBtna1=nGx6raiHDbRqibHWbZwFQ@mail.gmail.com>
References: <f946a3f5-8ff2-c8b3-41bd-d724418479c7@wavemetrics.com>
<CAAbtOZfj3AFJ1pVcBNJtCjqBtna1=nGx6raiHDbRqibHWbZwFQ@mail.gmail.com>
Message-ID: <CACTDJ6iSKWiuc1USLZgeWGOiTN3i0a0r+PAQkbXx-Bo+obUKeg@mail.gmail.com>

On Tue, Sep 17, 2019 at 7:55 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> This comes as an unwelcome shock, perhaps I should've known earlier. I
> maintain several XOP's which seem to be looking down the firing line of
> stopping working in upcoming months. It would help the community immensely
> if WM could give detailed guidance on what is required for XOP's to
> continue working.
>

It is a shock to us as well. We have known about the notarization
requirement for the application itself since Mojave was announced (reading
between the lines at least) and since 8.03 Igor has been notarized. Based
on the information provided with Mojave, and even after the WWDC announcing
Catalina, it was our impression that Igor would be able to set entitlements
that make it possible to load XOPs without them also needing to be signed
and notarized. Apparently that's not the case, though the documentation for
this aspect is still primarily in WWDC session slides, so calling it scarce
would be quite a compliment.

Note, however, that Apple has said that you will always be able to run any
software on your computer. It's right there, on page 40, at
https://devstreaming-cdn.apple.com/videos/wwdc/2019/701ngx868rfo8jlj/701/701_advances_in_macos_security.pdf?dl=1.
Of course, they probably won't tell you how.



> For example, could I request that the XOP manual be updated to show step by
> step instructions:
>

Since this requirement was sprung on us as well, we don't currently have
any documentation to provide to users and I can't give you a timeline as to
when/if we will develop such documentation. But most of the necessary steps
are documented somewhat acceptably by Apple. The exception is the
notarization process, which is buggy for XOPs.

https://docs.xojo.com/UserGuide:Mac_Code_Signing has a decent overview of
the process, though it doesn't have a lot of details.


>
> 1) how to obtain DeveloperID's
>
Start at https://developer.apple.com/programs/enroll/

I wonder how many XOP authors will stop at this stage alone.


> 2) how to get certificates
>

You need a "Developer ID" certificate to sign an application that will be
used on macOS and distributed outside of the app store.


> 4) how to compile the XOP with a hardened runtime
>

You don't need to do this. The application that loads a plugin bundle
(Igor, in the case of XOPs) is in control of whether or not hardened
runtime is enabled and declares which hardened runtime entitlements the
application needs (
https://developer.apple.com/documentation/security/hardened_runtime_entitlements?language=objc).
XOPs don't have any control over entitlements, which means that we must
request any entitlement that we think an XOP might need. If an XOP tries to
do something that requires an entitlement that Igor itself has not
requested, Igor will immediately crash with no error reporting (thanks
Apple!).

Hardened runtime only applies to Mojave (10.14) and later. That's why I
suggested that anyone doing tricky things with XOPs on Mojave or later test
with Igor 8.04. While it is possible for a user to work around the
notarization requirement for XOPs (which applies only to Catalina and
later), there's no way for a user to disable hardened runtime, and we must
have it enabled in Igor in able to be able to notarize Igor. Also, in case
you're wondering, we can't get around the XOP sign+notarize requirement by
not enabling hardened runtime in Igor. I've already tried that.

If XOP authors find that we need to request additional entitlements in Igor
to allow an XOP to run properly, we're open to doing that. Hopefully that
won't be necessary.

And just to clarify, hardened runtime is a code signing option, not a
compiler option. In fact, it is likely that you would not need to recompile
an existing XOP in order to code sign and notarize it as long as it was
built with the 10.9 SDK or later. We did not need to recompile any of our
shipping XOPs to get them notarized.



> 6) how to get signed bundles notarised (and things that could go wrong in
> this step).
>

So far, we have only used command line tools for notarization of XOPs,
because as I mentioned above we didn't need to rebuild the XOP to notarize
it. Xcode 10+ also has some support for notarization built in, but I can't
speak to how that works for XOPs.

https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow?language=objc
describes the process for notarizing using the command line.

There's a bug(feature?) in Apple's notarization service that prevents a
bundle with the .xop extension from being notarized. However if you rename
the .xop bundle to .app, then notarize, and then re-name it back to .xop,
things work OK.

Instead of using Xcode to export a package, I created a .dmg (after
renaming the .xop to .app as I mentioned above). I then used basically the
same workflow described on that page.

Make sure that you staple the ticket to the .xop bundle, not the .dmg you
use to submit the xop for notarization. When you do the actual staple
command, it doesn't matter if the bundle has the .xop or .app extension.
The notarization and staple process works based on code signatures and file
hashes, not on names.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://info-igor.org/attachments/20190918/3eb1185c/attachment.html>