3 ms·
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.
by lunixbochs 5y ago
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.
- Klonoar 5y agoI'm fairly certain that you just need to codesign --deep here, as that's all I've ever done.
- lunixbochs 5y agoThat 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.
- Klonoar 5y agoHmmm, interesting - if nothing else hopefully this comment exchange helps some wayward developer down the road!
- lunixbochs 5y agoI 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.
- saagarjha 5y agoDon’t use codesign --deep, it’s mostly broken. Sign manually from the inside out.
- Klonoar 5y agoYou'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.
- lunixbochs 5y agoI'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.
- Klonoar 5y agoHmmm, 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).