how do I notarize python module

Hello, I have a electron app. I want to notarize this app. But there is a problem about python module.


In my case, some user will use it offline, so I need prepare common python modules for them.


When I try to notarize app, Apple will return failed, and logs tell to me that python module (.so files) does not cotains a valid signature or a secure timestamp signature.


What can I do to make app notarized with python module?


Can I let apple ignore these python module in app or Is there a way to signature these python modules ?

Replies

When I try to notarize app, Apple will return failed, and logs tell to me that python module (

.so
files) does not cotains a valid signature or a secure timestamp signature.

What can I do to make app notarized with python module?

Sign them and give them a secure timestamp. For advice on this, see my Signing a Mac Product For Distribution post.

Can I let apple ignore these python module in app … ?

No. An

.so
file is a Mach-O image containing native code. That has to be signed and notarised. Failing to do this will a) block notarisation of your entire product, and b) can prevent the code from being loaded at runtime.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I can't sign code use codesign command.


I put python modules in my project, these modules format like

numpy-1.18.1-cp37-cp37m-macosx_10_9_x86_64.whl


when I sign my app, error log show

numpy-1.18.1-cp37-cp37m-macosx_10_9_x86_64.whl/numpy/core/_operand_flag_tests.cpython-37m-darwin.so not sign.


So I can't do that in your post.


How could I do?


for example:


my python modules in libs folder.


so this file structure is

libs:

  • numpy-1.18.1-cp37-cp37m-macosx_10_9_x86_64.whl
  • matplotlib-3.1.3-cp37-cp37m-macosx_10_9_x86_64.whl/


I can't run codesign -s III libs

I’m sorry but I’m not an expert on Python distribution; so, while I can explain what macOS requires, I can’t explain how you do that using Python’s build tools. My recommendation is that you pursue this via a Python support channel; you’re more likely to connect up with some who has relevant experience there.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Failing to do this will

a) block notarisation of your entire product, and

b) can prevent the code from being loaded at runtime.



these two results will happen together?


Can I ignore python module sign and notarize my product?

Can I ignore python module sign and notarize my product?

If you’re product contains unsigned native code, you won’t be able to notarise it.

If you somehow manage to get around that (let’s say you download the native code from your server), you may run into problems at runtime. Under some circumstances the Mac will check that the code signature of the native code is covered by a notarisation ticket and refuse to load it if it’s not.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you. It seems impossible to do this.

I very much doubt it’s impossible. My advice is that you investigate you Python packaging technology to see if it has built-in support for Mac code signing. If it doesn’t, you should be able to do this post-processing yourself.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This path:

numpy-1.18.1-cp37-cp37m-macosx_10_9_x86_64.whl/numpy/core/_operand_flag_tests.cpython-37m-darwin.so

Means you are adding raw .whl packages into your app and (probably) install the packages during the runtime.

Please - DO NOT do it. I know at least 2 reasons: 1. Security checks usually do NOT support going into .zip archives to check things there (like .whl one) nor registering paths going into some of them. 2. To unarchive such .zip-s you need to have secure TMP dirs to run the code from - this is not good idea. (Consider even running the app directly from opened archive without copying to /Application! Keep app immutable.)

Please - install the packages BEFORE creating .dmg and try to notarize .so-s properly. They will be packed anyway.