[Python-Dev] Mac popups running make test (original) (raw)

Ned Deily nad at acm.org
Tue May 12 01:05:58 CEST 2015

In article <CALWZvp4D4C3+z=Xw2USvQTDXsZhQMw9o6zoyZVM2UeECaW2QxA at mail.gmail.com>, Tal Einat <taleinat at gmail.com> wrote:

On Sun, May 10, 2015 at 9:07 PM, Carol Willing <_ _willingc at willingconsulting.com> wrote: > On 5/10/15 10:29 AM, Tal Einat wrote: > On Sun, May 10, 2015 at 5:07 PM, Brett Cannon <brett at python.org> wrote: >> On Sun, May 10, 2015 at 10:04 AM Skip Montanaro <skip.montanaro at 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#//appleref/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, nad at acm.org

More information about the Python-Dev mailing list