Plugin compiled on macOS Catalina for R23, not working on Big Sur?

kbar

@fwilleke80 it is what I do in my build system, for every build.

I automated my build system using Jenkins pipelines. But you can also just write bash scripts and batch files instead, since that is effectively what I do in Jenkins anyway.

My code is all pulled from GitHub, project tool runs, all additional 3rd party libraries are built, plugins compiled, signed, zipped up, sent to apple for notarization and then uploaded to AWS S3 and my customers can automatically down the new updates after any new build is marked as published.

Took a while to set up but is such a time saver in the end. I can build all my plugins for every version of C4D and have them available for customers with just one click. It’s a full rebuild every single time I press the button.

https://Jenkins.io. Then look at pipelines.

fwilleke80

Thanks, that's a good tip! I'll try that out!

By the way, @r_gigante , turns out my tester hat installed 23.008 on Big Sur, while I had compiled the plugin against 23.110... so... it works now. Thanks

Cheers,
Frank

fwilleke80

One follow-up question:

I have followed the steps described in https://developers.maxon.net/docs/cpp/2023_2/page_maxonapi_dev_macos.html#page_maxonapi_dev_macos_notarization_xcodecodesigning. Created a ZIP of my plugin (using Python, but it's still a normal ZIP, with the plugin binary, res folder etc.), signed it with my certificate from apple, and uploaded it using the xcrun altool --notarize-app ...and-so-on... call. Upload successful.

However, the plugin is never notarised, and looking into the notarisation history, it tells me:
2020-11-27 08:44:14 +0000 b1cb2d34-a374-40b4-95d3-64a5d9e4df38 invalid 2 Package Invalid

I saw posts on the web from people who had the same problem. They fixed it by enabling "Hardened Runtime" in their projects. I already did that, as described in the SDK docs, but the problem persists.

Is there any way to find out what's to invalid about the package?

Cheers,
Frank

fwilleke80

Oh wait, got it by displaying the notarisation log. The binary had no timestamp.

After googling a bit, I fixed it by adding --timestamp=http://timestamp.apple.com/ts01 to "Other Code Signing Flags", and it was notarised successfully!

Is --timestamp=http://timestamp.apple.com/ts01 a good choice for this flag? The SDK docs just say "include a secure timestamp with your code-signing signature;", which is not too much information

kbar

This post is deleted!

r_gigante

@fwilleke80 Thanks for the follow-up Frank! In all the previous cases I always notarized without specifying the timestamp. I'll again and in case update the guide.

Cheers, r

fwilleke80

How did you do it without a timestamp?
The SDK explicitly says a timestamp is needed:
https://developers.maxon.net/docs/cpp/2023_2/page_maxonapi_dev_macos.html#page_maxonapi_dev_macos_notarization_preliminary

But yes, a bit more detailed information would be appreciated

kbar

@fwilleke80 I think setting the hardened runtime when you code sign solves the timestamp issue. I don’t set a timestamp.

codesign --force --options runtime --sign 'Developer ID Application: YOURCOMPANYNAME' 'sdk/plugins/yourplugin/yourplugin.xlib'

fwilleke80

Ah, ok. I've got that enabled, too. I guess adding a timestamp doesn't hurt.

r_gigante

@kbar said in Plugin compiled on macOS Catalina for R23, not working on Big Sur?:

@fwilleke80 I think setting the hardened runtime when you code sign solves the timestamp issue. I don’t set a timestamp.

codesign --force --options runtime --sign 'Developer ID Application: YOURCOMPANYNAME' 'sdk/plugins/yourplugin/yourplugin.xlib'

Thanks a lot Kent, for pointing this out!
The one below is the string I use which, as said by Kent, doesn't need the timestamp because of the hardened runtime.
codesign -f -s "Developer ID Application: <YOUR DEV ID>" --options runtime <binary file>.xlib

Documentation updated accordingly