<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 7:55 PM Andrew Nelson <<a href="mailto:andyfaff@gmail.com" target="_blank">andyfaff@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This comes as an unwelcome shock, perhaps I should've known earlier. I<br>
maintain several XOP's which seem to be looking down the firing line of<br>
stopping working in upcoming months. It would help the community immensely<br>
if WM could give detailed guidance on what is required for XOP's to<br>
continue working.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://devstreaming-cdn.apple.com/videos/wwdc/2019/701ngx868rfo8jlj/701/701_advances_in_macos_security.pdf?dl=1" target="_blank">https://devstreaming-cdn.apple.com/videos/wwdc/2019/701ngx868rfo8jlj/701/701_advances_in_macos_security.pdf?dl=1</a>. Of course, they probably won't tell you how.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, could I request that the XOP manual be updated to show step by<br>
step instructions:<br></blockquote><div><br></div><div>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.</div><div><br></div><div><a href="https://docs.xojo.com/UserGuide:Mac_Code_Signing">https://docs.xojo.com/UserGuide:Mac_Code_Signing</a>  has a decent overview of the process, though it doesn't have a lot of details. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
1) how to obtain DeveloperID's<br></blockquote><div>Start at <a href="https://developer.apple.com/programs/enroll/" target="_blank">https://developer.apple.com/programs/enroll/</a></div><div><br></div><div>I wonder how many XOP authors will stop at this stage alone.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) how to get certificates<br></blockquote><div><br></div><div>You need a "Developer ID" certificate to sign an application that will be used on macOS and distributed outside of the app store.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">4) how to compile the XOP with a hardened runtime<br></blockquote><div><br></div><div>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 (<a href="https://developer.apple.com/documentation/security/hardened_runtime_entitlements?language=objc">https://developer.apple.com/documentation/security/hardened_runtime_entitlements?language=objc</a>). 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!).</div><div><br></div><div>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.

</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
6) how to get signed bundles notarised (and things that could go wrong in<br>
this step).<br></blockquote><div><br></div><div>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.</div><div><br></div><div><a href="https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow?language=objc">https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow?language=objc</a>  describes the process for notarizing using the command line.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Adam </div></div></div>