The main one is that there is an optional step (the “stapler”) that re-signs your package between notarization and publication, so that users’ computers can skip ahead and know that it’s OK without having to contact Apple at all. The documentation describes it as an ordered process : sign, then notarize, then publish. But I found it hard to see what was going on, partly because the documentation mostly refers to processes and tools rather than principles, and partly because there are so many other complicating factors to do with code-signing, identity, authentication, developer IDs, runtimes, and packaging - I’ll survey those in a moment.įor me, though, the moment of truth came when I realised that none of the above has anything to do with the release flow of your software. If not, the user gets an error dialog ( blah cannot be opened) and the action is rejected. If the server’s database has a record of the hashes and says they’re clean, the server returns “aye” and everything goes ahead.The user’s computer calculates locally the same cryptographic hashes of the binaries involved, then contacts Apple’s servers to ask “are these all right?”.Later, when someone else wants to run your application bundle or load your plugin or whatever: They scan them individually for malware and for each one (assuming it is clean) they file a cryptographic hash of the binary alongside a flag saying “yeah, nice” in a database somewhere, before returning a success code to you. Apple’s servers unpack it and pick out all of the binaries (executables, libraries etc) it contains.This may be an application bundle, or just a zip file with binaries in it. Your computer sends a pack of executable binaries off to Apple’s servers. Here’s what happens when you notarize something: But I want to write this as a conceptual note anyway.) What notarization does Apple docs, KVRaudio, Glyphs plugin documentation. (Everything here has been covered in other places before now, e.g. As a non-native Apple developer, I find this situation… trying.Īnyway, this week I realised I had some misconceptions about how notarization actually worked, and once those were cleared up, the rest became obvious. Complicating matters is the fact that notarization requirements are suspended for binaries built or downloaded before a certain date, so a host will often load old plugins but refuse new ones. In my case I’m dealing mostly with Vamp plugins, and the main host for them is Sonic Visualiser, or technically, its Piper helper program.Ĭatalina requires that applications (outside of the App Store, which I’m not considering here) be notarized before it will allow ordinary users to run them, but a notarized host application can’t always load a non-notarized plugin, the tools typically used to notarize applications don’t work for individual plugin binaries, and documentation relating to plugins has been slow in appearing. In particular I’ve had difficulty understanding how one should package plugins - shared libraries that are distributed separately from their host application, possibly by different authors, and that are loaded from a general library path on disc rather than from within the host application’s bundle. (I put notarization in quotes because it doesn’t carry the word’s general meaning it appears to be an Apple coinage.) I’ve spent altogether too long, at various moments in the past year or so, trying to understand the code-signing, runtime entitlements, and “notarization” requirements that are now involved when packaging software for Apple macOS 10.15 Catalina.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |