Latest pyzmq versions fail to pass Apple notarization

[TechnicalPirate]

Hello,

Problem: We convert our python tool into a binary using cx_freeze and pass it to Apple for notarization prior to deployment to client machines. When using Python 3.9 and pyzmq-22.1.0 - pyzmq fails to pass Apples notarization policies.

Looking at the pyzmq changelog i guess this would have started to manifest on version 21?

Notarization Error Report:

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libsodium.23.dylib",
    "message": "The binary is not signed.",
    "docUrl": null,
    "architecture": "x86_64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libsodium.23.dylib",
    "message": "The signature does not include a secure timestamp.",
    "docUrl": null,
    "architecture": "x86_64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libsodium.23.dylib",
    "message": "The binary is not signed with a valid Developer ID certificate.",
    "docUrl": null,
    "architecture": "arm64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libsodium.23.dylib",
    "message": "The signature does not include a secure timestamp.",
    "docUrl": null,
    "architecture": "arm64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libzmq.5.dylib",
    "message": "The binary is not signed.",
    "docUrl": null,
    "architecture": "x86_64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libzmq.5.dylib",
    "message": "The signature does not include a secure timestamp.",
    "docUrl": null,
    "architecture": "x86_64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libzmq.5.dylib",
    "message": "The binary is not signed with a valid Developer ID certificate.",
    "docUrl": null,
    "architecture": "arm64"
},

{
    "severity": "error",
    "code": null,
    "path": "OurApp.app/Contents/Resources/lib/zmq/.dylibs/libzmq.5.dylib",
    "message": "The signature does not include a secure timestamp.",
    "docUrl": null,
    "architecture": "arm64"
},

Desired Resolution : A way to use pyzmq inside "frozen" python app's and be able to pass Apples ( fickle 😂 ) notarization system :)

[TechnicalPirate]

For now my workaround is to use 19.0.2 which has Py3.9 support but not the .dylib issues :)

[minrk]

I guess the issue is that pyzmq has started bundling dylibs using delocate instead of as Python extensions, which use the .so extension instead of .dylib. Still, it is very strange that it only objects to the .dylib files, not the several (identical) unsigned shared libraries with the .so extension that are in all versions of pyzmq, including 19.0.2.

Do you have other dependencies that have compiled components (.so and/or .dylib)? e.g. numpy? Do they work?

Does it work to follow the pyinstaller steps to sign a bundle with the --deep option? I don't see cx_freeze docs for signing, but maybe a similar option exists.

[minrk]

@TechnicalPirate can you test with the mac-wheels artifact from this build? They have adhoc signatures due to an update to delocate. I think that might be enough.

[TechnicalPirate]

Hi @minrk - Just tried to build using this dependency, unfortunately it fails at the code signing (pre-notarization) stage with this error.

build/Our-App.app: invalid signature (code or signature have been modified)

In subcomponent: /Volumes/jenkins/workspace/our-app_PR-46/build/Our-App.app/Contents/Frameworks/libsodium.23.dylib

In architecture: x86_64

spctl check got an error: build/Our-App.app: invalid signature (code or signature have been modified)

...also incase it helps these are the commands we call code signing with :)

['spctl', '-vvv', '--assess', '--raw', '--verbose=10', '--type', 'exec', 'build/Our-App.app']

~Am just retesting now with 22.1.0 to confirm it passes this stage and fails on notarization~ Confirmed - 22.1.0 passes this stage, then fails on notarization

[minrk]

I'm out of ideas, then. Do you have other compiled dependencies that pass this check, e.g. numpy? It's never been the norm to sign wheel components, and I don't think anyone does it, to my knowledge, other than the brand new adhoc wheel signing in delocate (which isn't and shouldn't be trusted, but it is at least a signature). I think the only way to do it is 'deep' signing of your app that re-signs bundled components, and/or builds dependencies with your own code-signing toolchain.

It also seems pretty wild that it doesn't check .so libraries, only .dylib, since they include the same code and capabilities!

[TechnicalPirate]

Hey @minrk

Yep, some other dependencies are passing this check ( PySide2 for example ) and some are also failing.

Given i can work around this for now by using 19.0.2 version, there's no immediate urgency to have this resolved as i have ongoing battles with other parts our build pipeline. Once i have managed to clear a path I will circle back to this request with more information and we can try and work it out :)

[minrk]

Wonderful, thank you! A list of dependencies that do and don't work would be a help so I can try to see what is different.

pyside is a bit surprising, because it also fails validation when I check the wheel directly:

$ codesign -dvv PySide2/libpyside2.abi3.5.15.dylib
PySide2/libpyside2.abi3.5.15.dylib: code object is not signed at all

$ spctl -vvv --assess --raw --verbose=10  PySide2/libpyside2.abi3.5.15.dylib
PySide2/libpyside2.abi3.5.15.dylib: rejected
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>assessment:authority</key>
	<dict>
		<key>assessment:authority:flags</key>
		<integer>0</integer>
		<key>assessment:authority:source</key>
		<string>no usable signature</string>
	</dict>
	<key>assessment:remote</key>
	<true/>
	<key>assessment:verdict</key>
	<false/>
</dict>
</plist>

which is exactly the same as the result for pyzmq-22.1.0

[minrk]

optimistically closing some old build-related issues since builds have totally changed in v26. I also don't believe this is specific to pyzmq, since it follows the same practices as most other Python packages like numpy, pyside, etc.