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

fwilleke80

Btw, @kbar I had problems compiling my R20 plugins with Xcode 11, I run into a lot of debug breaks that all have to do with GePrint() and GeDebugOut(). With Xcode 10 that happens almost never, and with the good old Xcode 8.2.1, everything runs smooth... but 8.2.1 only runs on my old MacBook.

r_gigante

Hi @fwilleke80, I'm using 11.3 and I've no issue on running the plugin BigSur.

With regard having the code running on your customers' machine I think you need to notarise (is it what you mean by sign my plugins?) the plugins before giving them otherwise the security mechanism found in BigSur might easily have block them.

He has answered the usual security question that macOS shows him (as I don't sign my plugins yet), but no success.

Can you ask your customer what "usual" security questions he answered?
Can you ask your customer before unpacking the zip archive, that maybe he has downloaded from an email or a website, to run $ xattr -d "com.apple.quarantine <zip archive to your plugin>"

Cheers, R

kbar

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

Hmmm. Are you signing your plugins?

Yes I sign and notarize all my plugins as part of my build process. It can all be automated via command line.

kbar

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

With regard having the code running on your customers' machine I think you need to notarise (is it what you mean by sign my plugins?)

Code Signing and Notarizing are two separate things. First you sign your plugins, then you zip them up and send the zip to apple for notarization.

r_gigante

Thanks @kbar it's clear to me, I just wanted to know what actually @fwilleke80 was meaning. And for those listening you can sign a plugin during or after the building process.

Cheers, R

fwilleke80

Can you ask your customer what "usual" security questions he answered?

Can you ask your customer before unpacking the zip archive, that maybe he has downloaded from an email or a website, to run $ xattr -d "com.apple.quarantine <zip archive to your plugin>"

Ah, thanks, I'll ask him to try that!

So, to make the plugin run on my beta testers' Macs with Bir Sur without warnings, I not only need to sign the binary, I also need to send the binary to Apple to have it notarised? Every single time I release a beta version to my testers??

Cheers,
Frank

fwilleke80

Hm, tester days, he did the Terminal call, and he had the security warning when starting Cinema 4D (that the binary from my product is from an unknown developer, so it won't be loaded). He then opened his System Preferences >> Security & Privacy, and confirmed that the library should be loaded. But no success

r_gigante

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

Can you ask your customer what "usual" security questions he answered?

Can you ask your customer before unpacking the zip archive, that maybe he has downloaded from an email or a website, to run $ xattr -d "com.apple.quarantine <zip archive to your plugin>"

Ah, thanks, I'll ask him to try that!

So, to make the plugin run on my beta testers' Macs with Bir Sur without warnings, I not only need to sign the binary, I also need to send the binary to Apple to have it notarised? Every single time I release a beta version to my testers??

Cheers,
Frank

This is actually what we do in our building pipeline. My suggestion is to automate the process which, being completely terminal based, should be far from being rocket science.

Cheers, R

fwilleke80

That's what I gotta do then

Thanks & greetings,
Frank

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