> On 29 Oct 2018, at 00:56, Glyph <gl...@twistedmatrix.com> wrote: > > > >> On Oct 28, 2018, at 2:57 PM, Glyph <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >>> I wonder what the “hardened runtime” option actually does and enforces. >>> In 3.7 the line in ctypes/__init__.py that causes the exception is a call >>> that creates a dummy C function, and likely triggers the first allocation >>> for storing a libffi closure which could be something the hardened runtime >>> doesn’t like (being writeable + executable memory). >> >> Interesting. Perhaps what I want is simply >> https://developer.apple.com/documentation/security/com_apple_security_cs_allow-unsigned-executable-memory >> >> <https://developer.apple.com/documentation/security/com_apple_security_cs_allow-unsigned-executable-memory> >> then? Any chance you know how to jam that into a `codesign` command line >> somehow? :-) >> > > Thank you so much for this tip, Ronald! This was much easier than I > anticipated, and things are working now!
Great. > > The relevant entitlements file is literally just: > > <?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 > <http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> > <plist version="1.0"> > <dict> > <key>com.apple.security.cs.allow-unsigned-executable-memory</key> > <true/> > </dict> > </plist> > > I dropped that in a file, added `--entitlements=$THAT_FILE.plist` to my > codesign invocations, removed all my workarounds for ctypes et. al. (except > for the hard-coded 'import _cffi_backend' still necessary to convince > modulegraph to include enough code for SSL to work), and then tried launching > my app. Which package needs _cffi_backend? I can add a recipe for that to py2app to do this automagically. > Success! Then I tried notarizing it: also success! Time permitting, I'll be > updating my blog post at > https://glyph.twistedmatrix.com/2018/01/shipping-pygame-mac-app.html > <https://glyph.twistedmatrix.com/2018/01/shipping-pygame-mac-app.html> with > this information, and possibly publishing the now unfortunately somewhat > complex tooling I use to do signing now. > > So I don't know if I'm the first to do this, but looking at the archives for > these lists I seem to be the first to report it: you can successfully > codesign and notarize apps created with py2app and python 3.6! > > It seems to me that whatever "MAP_JIT" is (an mmap flag, I'm guessing?) > libffi needs to be using it for the memory it places synthetic closures into, > so that this entitlement won't be necessary with some future version of > Python. But it looks like Apple is not pushing particularly hard to > deprecate this one right now, thank goodness :-). MAP_JIT is a mmap flag that’s apparently introduced in 10.14. The slides at https://developer.apple.com/videos/play/wwdc2018/702/ <https://developer.apple.com/videos/play/wwdc2018/702/> mention this flag and the hardened runtime. I guess we should add this flag to the code in Modules/_ctypes/malloc_closure.c CPython) and in the similar code in PyObjC. The annoying bit is that the flag is new in 10.14, and CPython installers are created on 10.9 which means those won’t include the new flag for a long time. I’ll have to check if using MAP_JIT is ok when deploying on older macOS versions, or if the code should do a runtime version check. Ronald > > -glyph > _______________________________________________ > Pyobjc-dev mailing list > pyobjc-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org https://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
