Notarization + Staple for dylib

Hi devs! We are developing a plugin for Rhino3D for macOS therefore creating a dylib that our code uses. So far so good, with xcrun altool + xcrun stapler everything worked nice and dandy we notarized the dylib and stapled it all good before xcode 13.

Now with the change in notarization we are migrating to xcrun notarytool and it works nicely and the dylib is notarized no problems but xcrun stapler refuse to staple the dylib. The man page tells us that the dylib is not a valid format to be stapled.

Any suggestion on how to solve this problem? For reference this is what we do.

/usr/bin/ditto -c -k --keepParent <dylib_path> <zipped_dylib>

xcrun notarytool submit <zipped_dylib> --apple-id <myid> --password <password>  --team-id <team_id> --wait

xcrun stapler staple -v <dylib_path>

Thanks a lot!

Alberto

Up vote post of albertofranco Down vote post of albertofranco
483 views
Posted by
albertofranco
Reply
Add a Comment

Replies

we are migrating to xcrun notarytool

Yay!

but xcrun stapler refuse to staple the dylib

Well, yes.

The only question here is what you were previously doing. You can’t staple a ticket to a dynamic library because the code isn’t bundled and thus there’s no place to put the ticket. But even if you could, it wouldn’t help: The user doesn’t open your library directly and thus there’s no opportunity for Gatekeeper to ingest the ticket.

Note For more background about stapling, see the posts linked to from Notarisation Resources.

How do you ship your final product? In a zip archive? Or disk image? Or installer package? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Hello  @eskimo . I think to have the same problem like the OP.

There's a third-party application, properly notarized, that can be extended using "plugins" provided as "dylib" files. The third-party application works with such "plugins" using the classic dlopen()/dlsym()/dlclose() functions.

How can we provide to customers a dylib "plugin" without having troubles with Gatekeeper? (for example: do we have to code-sign the dylib? does using the dylib interacts with the notarization/os-security-checks of the third-party application?)

Thanks.

Posted by
Kafumanto
Up vote reply of Kafumanto Down vote reply of Kafumanto
Add a Comment