> On 28 Oct 2018, at 19:20, Glyph <gl...@twistedmatrix.com> wrote: > > > >>> >>> Curiously, this is the same traceback that comes from >>> https://forum.kodi.tv/showthread.php?tid=329171 >>> <https://forum.kodi.tv/showthread.php?tid=329171>, which suggests it's >>> something fundamental to strict shared-library sandboxing that ctypes trips >>> over when trying to initialize itself. >>> >>> Does anyone have experience with this, or ideas about what to do? >> >> I’m afraid not. I currently get away with not signing apps at all, although >> properly supporting signing is on my way too long wish list for py2app. > > The ability to distribute unsigned apps is not-so-slowly going away; even the > ability to distribute non-notarized apps has a very limited shelf-life at > this point. So this ought to be an alarming development for everyone - > having Python apps effectively banned from macOS distribution is a big > potential problem :-\.
Yup. That’s something that worries me as well, and not just for Python apps. Not being able to run your own code without paying Apple for the privilege is not something I look forward to. I’m still hoping that the option to run unsigned code doesn’t go away. > > The good news here is that aside from having to write a little for loop in > shell (shown below) getting the app codesigned previously was easy, and my > app *did* pass notarization, so nothing that py2app is doing is breaking > things on apple's end. It's just a matter of a ctypes bug. > > As I see it, there's 2 problems here: > > py2app's __boot__.py should fail more gracefully if initializing ctypes > doesn't work, since not everybody needs ctypes. Shall I file this on the > tracker? Yes please. I’d prefer a solution that doesn’t involve ignoring errors, but that’s probably the easiest fix for now. What’s the exception you’re getting? Tweaking the code in py2app/bootstrap/ctypes_setup.py to ignore that exception would be trivial. > ctypes itself should address whatever eldritch hideousness is causing this; > in addition to the windows security layer stuff I found, grsecurity TPE > causes the same traceback: https://bugs.python.org/issue28429 > <https://bugs.python.org/issue28429> >> With some luck there’s some entitlement or code signing option that causes >> this problem. What is the output of "codesign --display --verbose=4” for >> the application? Both with and without notarisation? > > Sorry, my original message was not clear. App notarization itself is not the > problem, it's the "stricter requirements" that I ambiguously referenced. The > requirement in question is the '--options runtime' flag passed to 'codesign'. > So you can just codesign an app (even with an ad-hoc identity, you > technically could do this without even having a valid cert, although the way > one generates one of those escapes me) with the 'runtime' option, you can > reproduce this. > > So if I sign my app like this: > > #!/bin/bash > find "${NAME}.app" -iname '*.so' -or -iname '*.dylib' | > while read libfile; do > codesign --sign "${IDENTITY}" \ > --deep "${libfile}" \ > --force \ > --options runtime; > done; > > codesign --sign "${IDENTITY}" \ > --deep "${NAME}.app" \ > --force \ > --options runtime; > > and then run it as "./${NAME}.app/Contents/MacOS/${NAME}". I immediately get > the traceback given above. Great. That should make it easier for me to reproduce the issue. Ronald
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
