Hacker News Reader

Comment by anonymouse008 | Hacker News Reader

Ha! Even though Notarizing was released in 2018, it's still too soon to discuss for me....

Try packaging a python interpreter with a ton of .so's and .dylibs with your .app and see how much hair you have left!

I ship my app as universal2 with latest Python (including modules and complex shared objects preinstalled to site packages such as Pytorch, numpy, opencv), xpc services, a launch daemon, a handful of frameworks, and ~137 shared objects in deeply nested subfolders. Fully notarized + stapled + hardened runtime + library validation. I don't build in Xcode, as this is a cross platform app. It's caused little stress. AMA.

(I also ship the same app to Windows with EV signing and I think that is more of a pain, due to the physical HSM requirement)

I’ve packaged and signed/notarized a Dolphin (fork) build and it was relatively painless all things considered. Dylibs have no real impact on this process so I’m curious what you ran into.

In python there are a handful of .so files in subdirectories you need to sign. You can basically `find . -name \*.dylib -o -name \*.so` and codesign those.

I'm fairly certain that you just need to codesign --deep here, as that's all I've ever done.

That seems to work if you put the entire Python stdlib under Frameworks but not if it's somewhere else.

I do the `find` thing because I pre-sign my libraries when I build them to save a bit of time during app build.

Hmmm, interesting - if nothing else hopefully this comment exchange helps some wayward developer down the road!

I can't remember, because I did this a few years ago, but I think there was some other code signing benefit to not putting all of Python in Frameworks as well.

Don’t use codesign --deep, it’s mostly broken. Sign manually from the inside out.

You're gonna need to expound on --deep being broken, considering I've not run into a single issue with it, and judging by the majority of blog posts/docs that cover this, others have the same experience.

I'm assuming it doesn't work well with nested bundle signing. As per my other thread it also seems to be picky about which subdirectories it signs, and there are lots of weird paths (LaunchDaemons, XPCServices, LoginItems, etc) you can put stuff in that needs signed. Not to mention if you put anything needing a sig in Resources.

Hmmm, well I'm willing to believe it then, yeah (although I definitely have a nested bundle setup in a project where --deep works fine... odd).

This is good to know though, and hopefully this exchange helps someone in the future too (actually, this would make for a good blog post - this kind of nuance is lost in most of the docs/existing posts).

If you're curious, Quinn (the Eskimo) has more details: https://developer.apple.com/forums/thread/129980

Perfect, exactly what I was looking for. Thanks!

Reply on news.ycombinator.com