In article <CALWZvp4D4C3+z=xw2usvqtdxszhqmw9o6zoyzvm2ueecaw2...@mail.gmail.com>, Tal Einat <talei...@gmail.com> wrote: > On Sun, May 10, 2015 at 9:07 PM, Carol Willing < > willi...@willingconsulting.com> wrote: > > On 5/10/15 10:29 AM, Tal Einat wrote: > > On Sun, May 10, 2015 at 5:07 PM, Brett Cannon <br...@python.org> wrote: > >> On Sun, May 10, 2015 at 10:04 AM Skip Montanaro <skip.montan...@gmail.com> > >> wrote: > >>> I haven't run the test suite in awhile. I am in the midst of running it > >>> on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: > >>> I assume this is testing some server listening on localhost. Is this a > >>> new thing, either with the Python test suite or with Mac OS X? (I'd > >>> normally be hidden behind a NAT firewall, but at the moment I am on a > >>> miserable public connection in a Peet's Coffee, so it takes on slightly > >>> more importance...) > >> It's not new. > > Indeed, I've run into this as well. > >>> I've also seen the Crash Reporter pop up many times, but as far as I > >>> could tell, in all cases the test suite output told me it was expected. > >>> Perhaps tests which listen for network connections should also mention > >>> that, at least on Macs? > >> Wouldn't hurt. Just requires tracking down which test(s) triggers it > >> (might be more than one and I don't know if answering that popup applies > >> for the rest of the test execution or once per test if you use -j). > > If anyone starts working on this, let me know if I can help, e.g. trying > > things on my own Mac. \> > I believe that the message has to do with OS X's sandboxing > > implementation and the setting of the sandbox's entitlement keys. Here's an > > Apple doc: > > https://developer.apple.com/library/ios/documentation/Miscellaneous/Referenc > > e/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/u > > id/TP40011195-CH4-SW9 > > I'm unaware of a way to work around this other than using Apple's code > > signing or adjusting target build settings in XCode :( If anyone knows a > > good way to workaround or manually set permission (other than clicking the > > Allow button), I would be interested. > I was reading about this a few weeks ago an recall finding a way to ad-hoc > sign the built python executable. Here's a link below. I haven't tried > this, though, and don't know if it would work with a python executable > rather than a proper OSX app. If it does work, it would be useful to add > this as a tool and/or mention it in the developer docs. > > http://apple.stackexchange.com/a/121010
I believe the issue has to do with the OS X application firewall and not sandboxing, as vanilla Python on OS X is not sandboxed. See: https://support.apple.com/en-us/HT201642 As described there, codesigned applications are automatically authorized to accept inbound connections; that's the workaround proposed in the apple.stackexchange cite. But arbitrarily signing development binaries after every compile is probably not a good idea. Another option is to configure the firewall but that probably only can be made to work with a framework build of Python which launches Python within an app bundle. In any case, please open an issue on the bug tracker so we can follow up on this. -- Ned Deily, n...@acm.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com